In #:if not MFC_CASE_OPTIMIZATION and USING_AMD (and #:if USING_AMD) branches, local arrays that are normally sized num_fluids / num_species / num_vels are instead given hardcoded sizes 3, 10, 20 with no constant or comment explaining the values. The #:else branch right below each shows what they stand for.
Sites:
src/common/m_chemistry.fpp:117-123 (dimension(10) :: Ys, omega vs num_species) and 160-169 (dimension(10) diffusion arrays).src/common/m_variables_conversion.fpp:1040-1050 (dimension(3) :: alpha_rho_K, alpha_K, vel_K; dimension(10) :: Y_K).src/simulation/m_compute_cbc.fpp — many: dimension(20), intent(inout) :: L; dimension(3) for dvel_ds/mf/dalpha_rho_ds; dimension(10) for dYs_ds.src/simulation/m_riemann_solvers.fpp:141-147 and ~10 more USING_AMD branches (L822, 1688, 1702, 1732, 1750, 3321, 4099, 4270, 4388).
Partial constant backing: num_fluids_max = 10 exists (m_constants.fpp:24), so the dimension(10) fluid arrays could use it. But there is no num_species_max or num_dims_max constant — the species 10, velocity 3, and CBC-vector 20 literals have no named backing. A clean fix needs new constants, not just substitution.
Why it's friction: these are deliberate AMD-compiler workarounds (fixed-size stack arrays, since AMD flang can't size device-routine arrays with non-constant bounds). If the species/fluid cap ever changes, these silent 10/20 literals can under-size and corrupt — and the value choice is undocumented (why 20 for the CBC L?).
Fix: add named constants (num_species_max, num_dims_max, a CBC-L size constant) and use them in the AMD branches, with a one-line comment that this is the AMD fixed-size-array workaround.
Dedup note: #1426 (m_riemann_solvers refactor) does not mention these AMD static dims — at most tangential.
Filed from a repo-wide code-cleanliness review; verified against master @ 40dde5e.
Code references
In
#:if not MFC_CASE_OPTIMIZATION and USING_AMD(and#:if USING_AMD) branches, local arrays that are normally sizednum_fluids/num_species/num_velsare instead given hardcoded sizes3,10,20with no constant or comment explaining the values. The#:elsebranch right below each shows what they stand for.Sites:
src/common/m_chemistry.fpp:117-123(dimension(10) :: Ys, omegavsnum_species) and160-169(dimension(10)diffusion arrays).src/common/m_variables_conversion.fpp:1040-1050(dimension(3) :: alpha_rho_K, alpha_K, vel_K;dimension(10) :: Y_K).src/simulation/m_compute_cbc.fpp— many:dimension(20), intent(inout) :: L;dimension(3)fordvel_ds/mf/dalpha_rho_ds;dimension(10)fordYs_ds.src/simulation/m_riemann_solvers.fpp:141-147and ~10 moreUSING_AMDbranches (L822, 1688, 1702, 1732, 1750, 3321, 4099, 4270, 4388).Partial constant backing:
num_fluids_max = 10exists (m_constants.fpp:24), so thedimension(10)fluid arrays could use it. But there is nonum_species_maxornum_dims_maxconstant — the species10, velocity3, and CBC-vector20literals have no named backing. A clean fix needs new constants, not just substitution.Why it's friction: these are deliberate AMD-compiler workarounds (fixed-size stack arrays, since AMD flang can't size device-routine arrays with non-constant bounds). If the species/fluid cap ever changes, these silent
10/20literals can under-size and corrupt — and the value choice is undocumented (why 20 for the CBCL?).Fix: add named constants (
num_species_max,num_dims_max, a CBC-L size constant) and use them in the AMD branches, with a one-line comment that this is the AMD fixed-size-array workaround.Dedup note: #1426 (m_riemann_solvers refactor) does not mention these AMD static dims — at most tangential.
Filed from a repo-wide code-cleanliness review; verified against
master@40dde5e.Code references
src/common/m_chemistry.fpp:117-123— dimension(10) AMDsrc/common/m_variables_conversion.fpp:1040-1050— dimension(3)/(10) AMDsrc/simulation/m_riemann_solvers.fpp:141-147— dimension(3)/(10) AMDsrc/common/m_constants.fpp:24— num_fluids_max=10