Read Riemann solver flux in place (skip flux_n copy) for HLLC / 5-eq #2100

Motivation

For HLLC with model_eqns = 2 (5-equation) on Cartesian grids, the Riemann solver writes its output into the 4D array flux_rs{x,y,z}_vf(x, y, z, var). s_finalize_riemann_solver then copies it into the scalar_field array flux_n(dir)%vf(var)%sf(x, y, z) that m_rhs and m_cbc read. The (x, y, z) subscripts are identical on both sides, so the kernel changes no values. It is a pure adapter between the solver output and the scalar_field layout, a bandwidth-bound kernel that runs several times per step. It also forces flux_n and flux_src_n to be allocated, plus flux_gsrc_n, which only cylindrical coordinates use.

Proposal

Add an internal flag flux_direct, decided once in s_initialize_global_parameters_module. When true:

• m_rhs (flux divergence, advection source terms) and m_cbc read flux_rs*_vf / flux_src_rs*_vf directly.
• The reshape in s_finalize_riemann_solver is skipped, and flux_n / flux_src_n are not allocated.
• flux_gsrc_n and flux_gsrc_rsx_vf are allocated only when cyl_coord is true.

The flag is enabled only for an explicit allow-list: HLLC, 5-equation, Cartesian, velocity-interface adv_src_mode, and none of alt_soundspeed, bubbles, qbmm, viscous, surface tension, hypoelasticity, heat conduction, chemistry, IGR, MHD, hyper-cleaning. All other configurations keep the existing path. MFC_NO_FLUX_DIRECT=1 forces the old path at runtime.

Access goes through two small fypp macros (FLUX_RD / FLUX_WR in macros.fpp). Kernels stay plain Fortran with the existing GPU_* macros.

Expected effect

Earlier numbers on an NVIDIA H200 (OpenACC, --case-optimization, base ~47568a0 plus local patches):

• about 7–10% lower grind time on 3D and 2D shock-droplet
• about 20 GB less GPU memory per device on the 3D case
• bit-identical restart output

These came from separate jobs, not interleaved, with about 1% cross-node noise. I am re-measuring on current master (3ef5e1e), including OpenMP offload and rank scaling, and will post those numbers and the ./mfc.sh test results on the PR.

Scope and risks

• Touches m_rhs.fpp, m_cbc.fpp, m_riemann_state.fpp, m_riemann_solvers.fpp, m_global_parameters.fpp, macros.fpp. I'll post the exact line count on the PR.
• m_cbc reads and writes the flux in many places (per direction and per boundary side). The change there is a mechanical substitution with the same macros, with no change to the CBC logic.
• Validated scope: only the allow-list above (an inviscid, Cartesian HLLC configuration, as in the 2D and 3D shock-droplet examples). Everything else is untouched. The approach could be extended, but each other reader of flux_n / flux_src_n (viscous, bubbles, other Riemann solvers, ...) would first have to read the solver output and be checked bit-for-bit. I'd rather keep this PR to what I can verify and leave the rest as follow-ups.

Additional context

I originally found this as an optimization opportunity while preparing MFC for the SC26 Student Cluster Competition. I have a fix ready and will open a PR soon as part of NTHU team (Team NTHU SCC)'s contribution.