register_default_materials() in default_materials.h is a hand-maintained list, and 8 of the 23 material classes are missing from it. A material that is not registered cannot be named in a JSON document at all.
Probed against the factory directly:
registered types: 19
small_strain_plasticity NOT REGISTERED -> unusable from JSON
rk_plasticity NOT REGISTERED -> unusable from JSON
linear_isotropic_hardening NOT REGISTERED -> unusable from JSON
exponential_isotropic_hardening NOT REGISTERED -> unusable from JSON
linear_damage_law NOT REGISTERED -> unusable from JSON
curing_rate NOT REGISTERED -> unusable from JSON
strain_energy_state_function NOT REGISTERED -> unusable from JSON
vector_strain_state_function NOT REGISTERED -> unusable from JSON
Why this matters more than the count suggests
small_strain_plasticity and linear_isotropic_hardening are both on the list, so a JSON document cannot express J2 plasticity — the library's flagship model. The document layer (#30) can build elasticity and damage and essentially nothing else. Against the goal of the library being JSON/config driven, that is the gap that matters.
Why nothing catches it
Registration is a list someone must remember to extend, and every test that uses these materials constructs them in C++ directly via ctx.create<T>(params) — never through the factory. So the tests pass, the material works, and the only thing broken is the path the config layer depends on. There is no signal anywhere.
Options
- Register them. Most are ordinary materials and the omission looks accidental.
- If any are deliberately not for JSON —
plasticity_utils-style internals, or materials whose parameters cannot be expressed in a document (small_strain_plasticity takes a yield_function object) — say so explicitly rather than by omission. drucker_prager_yield_function is passed as a typed parameter, so materials taking one may genuinely need a JSON representation for it first.
The second case is the interesting one: p.insert<dp_yield>("yield_function", yf) is a C++ object, and the JSON reader registry has no converter for it. That may be the real reason plasticity is absent, in which case this issue is "make yield functions expressible in JSON" rather than "add a line to a list".
Preventing recurrence
A generic registry-conformance test — see the companion issue — asserts that every class deriving material_base is either registered or on an explicit opt-out list. That turns this from a thing you have to remember into a thing that fails.
register_default_materials()indefault_materials.his a hand-maintained list, and 8 of the 23 material classes are missing from it. A material that is not registered cannot be named in a JSON document at all.Probed against the factory directly:
Why this matters more than the count suggests
small_strain_plasticityandlinear_isotropic_hardeningare both on the list, so a JSON document cannot express J2 plasticity — the library's flagship model. The document layer (#30) can build elasticity and damage and essentially nothing else. Against the goal of the library being JSON/config driven, that is the gap that matters.Why nothing catches it
Registration is a list someone must remember to extend, and every test that uses these materials constructs them in C++ directly via
ctx.create<T>(params)— never through the factory. So the tests pass, the material works, and the only thing broken is the path the config layer depends on. There is no signal anywhere.Options
plasticity_utils-style internals, or materials whose parameters cannot be expressed in a document (small_strain_plasticitytakes ayield_functionobject) — say so explicitly rather than by omission.drucker_prager_yield_functionis passed as a typed parameter, so materials taking one may genuinely need a JSON representation for it first.The second case is the interesting one:
p.insert<dp_yield>("yield_function", yf)is a C++ object, and the JSON reader registry has no converter for it. That may be the real reason plasticity is absent, in which case this issue is "make yield functions expressible in JSON" rather than "add a line to a list".Preventing recurrence
A generic registry-conformance test — see the companion issue — asserts that every class deriving
material_baseis either registered or on an explicit opt-out list. That turns this from a thing you have to remember into a thing that fails.