Generate m_thermochem as Fypp source using MFC's conventions

[sbryngelson]

Summary

Follow-up to #1915. The generated m_thermochem was a standalone Fortran file with its own sp/dp kinds and a #define GPU_ROUTINE shim, chosen per build from --single and --gpu. It is now Fypp source that follows MFC's conventions:

• #:include 'macros.fpp', use m_precision_select, only: wp, real(wp) and _wp literals.
• Device routines are marked with $:GPU_ROUTINE(function_name='...', parallelism='[seq]'), so OpenACC/OpenMP/CPU directive emission and any compiler-specific handling happen in MFC's macros, not in the generator.
• One generated source serves every precision and offload configuration, so generate_fortran no longer takes scalar_type or offload, and run/input.py loses the precision/offload plumbing.

The generated file is written as build/modules/<target>/m_thermochem.fpp; cmake/Fypp.cmake already preprocesses *.fpp there. The template is renamed module.fpp.mako.

Two small consequences:

• syscheck is built without MFC's common sources (HANDLE_SOURCES(syscheck OFF)), so it has no m_precision_select. It never used m_thermochem, so the toolchain stops generating it for that target.
• The generator's 80-column line wrapper now leaves Fypp directive lines ($:, #:, @:) whole.

What this does not do

The two call-site workarounds around m_thermochem stay: callers forming R_species = gas_constant/molecular_weights because nvfortran cannot pass the parameter array into a declare-target routine, and species properties evaluated in the loop body because CCE faults one routine deeper. Neither is a directive problem, so moving to $:GPU_ROUTINE does not address them, and I could not test nvfortran or CCE here.

Testing

• amdflang 23.2.1, OpenMP offload, MI250X (--gpu mp, OMP_TARGET_OFFLOAD=MANDATORY): ./mfc.sh test --only Chemistry - 16 passed, 0 failed against the existing goldens.
• gfortran 12.2 CPU: --only Chemistry - 16 passed, 0 failed.
• toolchain/mfc/test_thermochem.py (15 tests): the kernel tests now run the generated source through Fypp with MFC's include paths, as the build does, and compile it with m_precision_select.f90; double, single (-DMFC_SINGLE_PRECISION), mixed, and OpenACC/OpenMP (-DMFC_OpenACC/-DMFC_OpenMP) variants all compare against Cantera. I also checked that the same generated source preprocesses to !$acc routine seq, !$omp declare target device_type(any), and no directive on CPU.
• ./mfc.sh precheck passes.

Worth watching in CI: nvfortran OpenACC and CCE (Frontier) lanes, which are the ones I could not run.

Prepared with Claude Code.

Contribution Policy

We do not accept pull requests generated primarily by AI without genuine understanding or real-world usage context.

All contributions are expected to demonstrate:

• A clear understanding of the codebase
• Alignment with product direction
• Thoughtful reasoning behind changes
• Evidence of real-world usage or hands-on experience with the problem

If these expectations are not met, we would prefer to implement the changes ourselves rather than spend time reviewing low-effort submissions.

---

Acknowledgement

• I confirm this PR meets the above expectations and reflects my own understanding and real-world context.

---

PR template credit: junegunn

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[github-actions]

Claude Code Review

Head SHA: 7d0bf93

Files changed:

• 7
• docs/documentation/thermochemistry.md
• toolchain/mfc/run/input.py
• toolchain/mfc/test_thermochem.py
• toolchain/mfc/thermochem/init.py
• toolchain/mfc/thermochem/fingerprint.py
• toolchain/mfc/thermochem/fortran.py
• toolchain/mfc/thermochem/module.fpp.mako

Findings:

• toolchain/mfc/test_thermochem.py: the new fypp() helper (lines 56-64) always invokes Fypp with a fixed define set (MFC_COMPILER, MFC_CASE_OPTIMIZATION, chemistry) and never threads the offload/precision arguments of compile_kernel into it. Since $:GPU_ROUTINE(...) in module.fpp.mako is resolved entirely at Fypp-preprocessing time (before gfortran ever runs), the -DMFC_OpenACC/-DMFC_OpenMP flags added to the gfortran invocation (line 75, flags = {..., "acc": [...,"-DMFC_OpenACC"], "mp": [...,"-DMFC_OpenMP"]}) can no longer influence which directive text gets emitted — that decision was already baked into the .f90 file by the earlier, offload-agnostic fypp() call. test_precision_and_directives (parametrized over ("dp","acc")/("dp","mp")) therefore compiles the exact same generated source for both the "acc" and "mp" cases (and probably without the intended !$acc routine/!$omp declare target directive at all), so it no longer actually exercises the OpenACC/OpenMP code paths of $:GPU_ROUTINE even though it appears to — a silent loss of the GPU-directive coverage this test was written to provide.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 61.48%. Comparing base (fef3c27) to head (7d0bf93).

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #1917   +/-   ##
=======================================
  Coverage   61.48%   61.48%           
=======================================
  Files          86       86           
  Lines       22485    22485           
  Branches     3298     3299    +1     
=======================================
  Hits        13826    13826           
  Misses       6206     6206           
  Partials     2453     2453           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.