You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Tracking: follow-up refactors for the reacting immersed-boundary surface chemistry (#1821) #1893
Tracking issue for the #1821 follow-ups, so the ordering is written down somewhere.
#1821 landed heterogeneous immersed-boundary surface chemistry as a single 2733-line change. It is reviewed and working, and splitting it retroactively would be churn — but the pieces inside it have different owners, different test strategies, and in one case a different repository.
Nothing else. The remaining ~1400 lines are an example, its mechanisms, generated goldens, and ordinary parameter plumbing. Those are the right size and in the right place — this is not an argument that Add heterogeneous reacting surface boundary conditions #1821 should have been four PRs.
Why bother
The two extractions are what make the feature independently testable. Codecov reports 56.97% patch coverage on #1821 with 55 uncovered lines in m_ibm.fpp; the solver and the codegen are precisely the parts currently reachable only through a full 2-D reacting simulation compared against a golden. Both have already produced bugs that unit tests would have caught cheaply (a sticking-coefficient rate emitted as plain Arrhenius; a sum-constraint closure landing on a trace radical).
#1891 — codegen to pyrometheus. Open as pyrometheus/pyrometheus#118: generate_surface on all three backends, emitting a surface module that refers to the gas one, which is the shape MFC already consumes. Verified against Cantera to ≤1.5e-14 on two mechanisms, with the Fortran and C++ figures from compiled binaries. Handles the two forms the hand-written generator gets wrong or rejects (sticking coefficients, coverage dependence), so the MFC-side swap removes ~400 lines and lifts restrictions at the same time.
A second bug fell out of it, unrelated to surfaces: generating from a mechanism with no reactions produced code that raised IndexError when called, not merely unused locals. Filed as pyrometheus/pyrometheus#119, fixed in pyrometheus/pyrometheus#120.
#1892 — extract the solver module. Not started. It rewrites m_ibm.fpp, which #1821 is still changing, so it wants #1821 merged first or the conflict is guaranteed.
Ordering unchanged: #118 lands upstream, then #1891 here, then #1892. Nothing in this tracker is blocked on anything in MFC except #1821 merging.
Activity
sbryngelson commentedon Sep 18, 2026
Status on the upstream item.
#1891 — codegen to pyrometheus. Open as pyrometheus/pyrometheus#118:
generate_surfaceon all three backends, emitting a surface module that refers to the gas one, which is the shape MFC already consumes. Verified against Cantera to ≤1.5e-14 on two mechanisms, with the Fortran and C++ figures from compiled binaries. Handles the two forms the hand-written generator gets wrong or rejects (sticking coefficients, coverage dependence), so the MFC-side swap removes ~400 lines and lifts restrictions at the same time.A second bug fell out of it, unrelated to surfaces: generating from a mechanism with no reactions produced code that raised
IndexErrorwhen called, not merely unused locals. Filed as pyrometheus/pyrometheus#119, fixed in pyrometheus/pyrometheus#120.#1892 — extract the solver module. Not started. It rewrites
m_ibm.fpp, which #1821 is still changing, so it wants #1821 merged first or the conflict is guaranteed.Ordering unchanged: #118 lands upstream, then #1891 here, then #1892. Nothing in this tracker is blocked on anything in MFC except #1821 merging.
sbryngelson commentedon Sep 25, 2026
no more pyro so this isn't needed