[k-yoshimi]

Fixes #253 (develop-targeted, so close by hand after merge).

Why

tr_set_param / fp_set_param / ti_set_param cleared the module's private g_prepared flag themselves. tot's tr: / fp: / ti: dispatcher (tot/tot_param_registry.f90) calls tr_param_set & co. directly, so a set through Tot (or tot_mcp) after a run left the flag standing: the next tot_run continued the old state with tr_prep skipped, the #189 pre-run species check never fired, and Tot.set_param("tr:NSMAX", 3) + run could still produce NaN. TotPipeline was not affected (it goes through the per-module wrappers), so the two tot front ends disagreed silently.

What

The registry counts, the API compares. Each of tr_param_registry, fp_param_registry, ti_param_registry gets a private g_generation that every successful set advances (the old bodies become *_param_set_impl; the public names are two-line wrappers, so an early RETURN inside the SELECT CASE cannot skip the count and a refused set leaves it alone), and a read-only accessor <mod>_param_generation(). tr_api / fp_api / ti_api keep g_prepared, add g_prep_generation, and re-prep when .NOT. g_prepared .OR. g_prep_generation /= <mod>_param_generation(); the explicit g_prepared = .FALSE. in the setters is gone, so there is one mechanism. Whoever reaches the registry (the C ABI setter, tot's dispatcher, a future caller) invalidates the prep.

Scope: *_param_registry.f90 (L-3 registry) and *_api.f90 (L-2 C ABI) only. No trprep / trloop / physics change, so this is outside the lead-sign-off rule for Fortran body changes.

Behaviour change, Tot and tot_mcp only: a set after a run now restarts the module (NT, T back to 0), which is what trlib / fplib / tilib / TotPipeline have always done. No test or baseline relied on the old continue semantics (checked: no Tot test sets a tr: parameter after a run and runs again; totregress.f90 reads a namelist). A "live" coupling input that should not restart the module (EXTERNAL_DRIVEN_I is the candidate) would need a live/structural classification in the registry; that is a follow-up, not this PR.

eq has no prepared flag on develop, so no counter there; #256's g_has_equilibrium is the natural consumer and I will suggest the same shape on that PR.

Tests (python/totlib/tests/test_set_after_run.py, 5 cases)

• Tot: run(2) → nt == 2, set_param("tr:DT"), run(1) → nt == 1; Trlib with the same sequence agrees.
• Tot: run(1), set_param("tr:NSMAX", 3) (species 3 has PN = PNS = 0), run(1) raises: the tr_tst2 fixture: NSMAX>2 mutation produces NaN scalars (RNU/RTU species 3+ unpopulated) #189 check is reached. Fails on develop.
• A set the registry refused does not restart (nt == 3).
• fp and ti on the mono image (MONO_LIB_PATH, CI's mono routing step; skipped elsewhere) with raw ctypes: tot_init, <mod>_run, tot_set_param("<mod>:NRMAX", 20), <mod>_run. fp: fp_get_state().nrmax == 20 (it reports the allocated extent, fix(fp): bound fp_get_state copies by the allocated extents (#245) #248, so this holds only if fp_prep reallocated). ti: ti_get_state reports NRMAX straight from the namelist, so the observable is NT: ti_run(2), set, ti_run(1) ends at nt == 1 only after a re-prep (3 when the old state continues). The ti case uses tilib's TiDataCwdMixin for the ADPOST data cwd. Not on the default libtotapi.so: it links the sibling lib*api.so, each with its own PIC copy of pl / eq / bpsd, and on Linux ELF interposition binds the duplicates to the first-loaded copy, so fp_run reached through it mixes copies and crashed on CI (SIGSEGV / SIGBUS; macOS's two-level namespaces hid it locally). Running fp / ti alongside tot in one process is what the mono image is for.

Verification

• Local (macOS gfortran): tr/fp/ti .so, libtotapi.so, libtotapi_mono.so rebuilt; the new file 3 passed + 2 mono-skipped without MONO_LIB_PATH, 5 passed with it; pytest python/totlib/tests python/trlib/tests python/fplib/tests python/tilib/tests python/mcp-servers/tot_mcp python/mcp-servers/tr_mcp --forked --timeout=120 --timeout-method=signal → see the first comment; make -C tot tot_api_check_so → see the first comment.
• Against a develop build (fresh clone of develop @ f41fe5b, same test file): the two Tot restart/refusal cases fail (nt 3 instead of 1, no refusal) and, driven the same way against develop's libraries, fp nrmax stayed 1 and ti nt ended at 3; the refused-set case passes; with the fix all pass.
• Reviews: in-house + Codex (first comment).

🤖 Generated with Claude Code

https://claude.ai/code/session_01TA2KahTs3qLMZL6yjSsWwT

[k-yoshimi]

Pre-push reviews (in-house + Codex, both read-only on 52ad20e8 → re-checked at 2eb8cd11; the final 73d8e0a differs only by the two LOW fixes below and the README paragraph).

Verified by the reviewers against the code: the *_param_set → *_param_set_impl rename is complete for every public entry point (tr ×2, fp ×2, ti ×1), no caller references the _impl names, tot's dispatcher USEs only the public wrappers (so it is counted now), the C-ABI drivers call only the C symbols; g_generation is SAVE'd module state that neither init nor finalize reset, which is fine because both set g_prepared = .FALSE. and the run condition ORs the two; a failed prep (and tr's pre-prep refusals: NSM bound, #189 check) returns before the snapshot, so the next run retries; the only uses of g_prepared in the three API modules are declaration / init / run / finalize; per-module wrapper behaviour is unchanged (successful set → count moves → re-prep; refused set → no count → no clear, as before); dlsym on libtotapi.so reaches fp_run / ti_run in its DT_NEEDED lib*api.so (glibc searches the dependency tree; RTLD_LOCAL only hides them from other objects), i.e. the same copies dispatch_fp / dispatch_ti wrote to; fp's observable is the allocated extent (#248), ti's is NT (tiprep.f90:344 resets it); TotlibInvalidParamError / TotlibCalculationFailedError both subclass TotlibError; no existing test or baseline relies on tot's old continue semantics.

Findings, all applied:

• LOW (in-house): the skip guards were decorator-time skipUnless on mutable preconditions (the pattern Bugbot flagged twice on test: FIXTURES_DIR fallback for sweep + property_fanout (#192) #221); moved into setUp. MONO_LIB_PATH is made absolute before TiDataCwdMixin chdirs.
• LOW (Codex): README said fp: / ti: restart "on the next Tot.run", but tot_run drives tr_run only; reworded (next fp_run / ti_run).
• HIGH (Codex), not fixable here, documented: on the mono image several registries write the same plcomm variables (ti_param_registry USEs plcomm for RR/RA/RKAP/RDLT/BB/RIP, so ti:RR and eq:RR are one RR), and a set through one module's registry moves that module's count only. This is the mono image's pre-existing shared-storage property, present on develop exactly the same way (the old per-setter clear was per module too); a plcomm-owned counter would need a pl Fortran body change. Tracked in the follow-up issue linked below, noted in python/totlib/README.md.

Local: pytest python/totlib/tests python/trlib/tests python/fplib/tests python/tilib/tests python/mcp-servers/tot_mcp python/mcp-servers/tr_mcp --forked --timeout=120 --timeout-method=signal → 470 passed, 26 skipped, 1 failed (test_close_raises_exception_group_when_multiple_modules_fail, the known macOS / py3.10 ExceptionGroup case, unrelated). make -C tot tot_api_check_so → OK. New file: 5 passed + 2 mono-skipped on the default image, 7 passed with MONO_LIB_PATH; against a fresh develop build the two Tot cases and the fp / ti cases fail as described in the body.

[k-yoshimi]

CI on 73d8e0a failed in one test only: test_fp_reprepares_after_tot_set on the default libtotapi.so crashed on Linux (SIGSEGV / SIGBUS), while the same fp / ti cases on the mono image and the three Tot cases passed. Cause: the default image carries five PIC copies of pl / eq / bpsd (one per sibling lib*api.so), and on ELF the linker picks one definer per symbol across the copies, so the state tot_init prepared and the state fp_run touches need not be the same copy; macOS hid it. No product path calls fp_run / ti_run through libtotapi.so after tot_init, so fc74f00 runs those two cases on the mono image only (CI's mono step) and says why in the docstring; the hazard itself is recorded on #260. Both reviewers re-checked the delta (clean / wording applied).