solvers: select the integration scheme by name (explicit vs implicit from the deck)

[petlenz]

Stacked on #40, which is where j2_rk_plasticity exists.

The question that found this

"What if I want a different solver — maybe explicit? I could not simply define that in the JSON file."

Checking that turned out to be worth more than the answer. Three documents:

j2_rk_plasticity (sdirk3, implicit)        Key tableau not found
j2_rk_plasticity EXPLICIT (forward_euler)  Key tableau not found
a typo in the scheme name                  Key tableau not found

"tableau" was never declared in the schema

The constructor read get_parameter<const butcher_tableau*>("tableau"). parameters() never inserted it. So it worked only from C++, where parameter_handler::insert() bypasses the schema — and from a document it failed identically whether the name was right, wrong, or absent.

That matters more than a missing parameter usually would, because the tableau is the explicit-versus-implicit choice. j2_rk_plasticity already handles explicit stages:

m_is_implicit[i] = std::abs(m_diag[i]) >= 1e-30;

So forward_euler was always an explicit J2 integrator. The capability existed and was unreachable from a deck.

Third instance of one pattern

• zero_blocks in vector_newton — read via contains(), never declared (Add vector_newton: coupled Newton for mixed scalar/tensor local systems #17)
• yield_function in Drucker-Prager — a C++ object, never declared (8 materials are not registered in the factory, so a JSON model cannot express plasticity #33, fixed in materials: collapse small_strain_plasticity into a dedicated Drucker-Prager (unblocks #33) #43)
• tableau here

A parameter the code reads but the schema does not declare is invisible to both the document layer and to validation. I had been treating these as three unrelated bugs.

The change

tableau is now a scheme name, resolved by tableau_by_name(), and it is declared. rk_integrator had the identical defect and is fixed the same way — leaving one of the two would have been worse than not starting.

An unknown name throws and lists the valid schemes rather than leaving the parameter absent:

butcher_tableau: unknown scheme 'sdirk4' -- expected one of: forward_euler,
explicit_midpoint, rk4, implicit_euler, implicit_midpoint, crank_nicolson,
sdirk3, gauss_legendre_4

Result

j2_rk_plasticity (sdirk3, implicit)        OK
j2_rk_plasticity EXPLICIT (forward_euler)  OK
a typo in the scheme name                  unknown scheme 'sdirk4' -- expected one of: ...

Two tests: every published scheme resolves and reports the right explicit/implicit character (forward_euler and rk4 explicit, sdirk3 and gauss_legendre_4 not), and a typo names itself and the alternatives.

55/55.

What this does not fix

The solver type is still compile-time fixed in j2_plasticity and drucker_prager_plasticity — using solver_type = local_newton<Traits>, wired by dynamic_cast. A document names which instance, never which kind. Naming a backward_euler there still reports the material as missing rather than as the wrong type, because wire_materials() collapses every exception into "absent".

That is a separate change and arguably not needed: choosing the integrator by material type — j2_plasticity for implicit backward Euler, j2_rk_plasticity with a named scheme for everything else — is the same idiom as #40's backward_euler vs local_newton, and it avoids virtual dispatch on a per-integration-point path. Detail on #40.

Also here: the wiring error pointed the wrong way

wire_materials() wrapped the look-up and the type-check in one catch (...), discarding material_ref::wire()'s precise message. Naming a backward_euler where a local_newton is required produced:

wire_materials(): material 'j2' references missing materials: 'solver'

— sending the user to look for a material sitting right there in their document. The message did not just omit information, it pointed the wrong way. Now:

wire_materials(): material 'j2' references materials of the wrong type:
'solver' (they exist, but are not the type this material requires)

Both failure kinds are still collected and reported together, so a graph with one of each names both in one error. Two tests, one per mode; the wrong-type one is verified against the mutation that restores the single catch (...).

57/57.