Found by numsim-codegen's Phase-B end-to-end gate (NumSim-Stack/numsim-codegen#140 has the downstream side); verified 2026-08-02.
Symptom: NumSimMaterialEndToEnd.J2PathDependentRetainsPlasticStrainOnUnload — a codegen-emitted path-dependent J2 material (tensor εᵖ history, backward_euler solver, G=80, sy=1.0, H=10) is loaded to ε00=0.020 (εᵖ00 reaches 0.00775), then unloaded elastically to ε00=0.010. Expected: εᵖ retained (no plastic flow on elastic unloading). Observed on feature/vector-solver @ 0ea3801: εᵖ00 grows to 0.01199 during the unload step.
Bisection facts:
- Pinned contract aaa6614 (feature/drucker-prager) — all 17 e2e tests PASS, including this one.
- aaa6614 is an ancestor of 0ea3801, so the behavior change entered on the vector-solver work between those commits.
- Same generated material, same numsim-core (a160408), same compiler either way — only the numsim-materials checkout differs.
Question for you: is this an intended semantic change to backward_euler/return-map behavior on the branch (e.g. around the #13 clamp / Kuhn-Tucker handling), or an accidental regression? Either answer is fine downstream, but numsim-codegen cannot bump its _ncg_materials_pin past aaa6614 until this is resolved or the emitted-material contract is adjusted to match — its CI e2e gate will go red on the bump otherwise. (numsim-codegen now warns at configure time when a local checkout drifts from the pin, which is how this surfaced.)
Repro downstream: numsim-codegen cmake -B build && cmake --build build --target numsim_material_check_driver && ./build/tests/numsim_material_check_driver --gtest_filter='*J2PathDep*' with NUMSIM_MATERIALS_DIR pointing at the vector-solver checkout.
Found by numsim-codegen's Phase-B end-to-end gate (NumSim-Stack/numsim-codegen#140 has the downstream side); verified 2026-08-02.
Symptom:
NumSimMaterialEndToEnd.J2PathDependentRetainsPlasticStrainOnUnload— a codegen-emitted path-dependent J2 material (tensor εᵖ history, backward_euler solver, G=80, sy=1.0, H=10) is loaded to ε00=0.020 (εᵖ00 reaches 0.00775), then unloaded elastically to ε00=0.010. Expected: εᵖ retained (no plastic flow on elastic unloading). Observed onfeature/vector-solver@ 0ea3801: εᵖ00 grows to 0.01199 during the unload step.Bisection facts:
Question for you: is this an intended semantic change to
backward_euler/return-map behavior on the branch (e.g. around the #13 clamp / Kuhn-Tucker handling), or an accidental regression? Either answer is fine downstream, but numsim-codegen cannot bump its_ncg_materials_pinpast aaa6614 until this is resolved or the emitted-material contract is adjusted to match — its CI e2e gate will go red on the bump otherwise. (numsim-codegen now warns at configure time when a local checkout drifts from the pin, which is how this surfaced.)Repro downstream: numsim-codegen
cmake -B build && cmake --build build --target numsim_material_check_driver && ./build/tests/numsim_material_check_driver --gtest_filter='*J2PathDep*'withNUMSIM_MATERIALS_DIRpointing at the vector-solver checkout.