MFC convention: no d-exponent literals (5.0d-11 → 5.0e-11_wp); no precision-implicit bare literals where a real(wp) is expected (add _wp); loop counters must be plain integer, not integer(wp).
(a) d-exponent literal — src/simulation/m_bubbles_EL.fpp:1345
if ((1._wp - q_beta(1)%sf(i, j, k)) > 5.0d-11) then
Fix → 5.0e-11_wp. Note: the source linter's d-literal regex ([0-9]d0) only catches ...d0, so 5.0d-11 slips through. This is the only d-literal remaining in src/. Output-neutral (same value).
(b) integer(wp) loop counter — src/simulation/m_bubbles_EE.fpp:73
integer(wp) :: i, j, k, l
wp is a real kind; using it as an integer kind is wrong/non-portable. Fix → integer. Only occurrence in src/. Output-neutral.
(c) Bare literals missing _wp (add _wp, value unchanged):
(d) HardcodedIC — golden-gated, NOT output-neutral:
Why it matters: d-literals and bare-real literals break single/mixed-precision builds (--single, --mixed) — a 1.e-6 literal is real32 regardless of wp, silently changing results in mixed mode. integer(wp) is outright type-incorrect.
Filed from a repo-wide code-cleanliness review; locations verified against master @ 40dde5e.
Code references
MFC convention: no
d-exponent literals (5.0d-11→5.0e-11_wp); no precision-implicit bare literals where areal(wp)is expected (add_wp); loop counters must be plaininteger, notinteger(wp).(a)
d-exponent literal —src/simulation/m_bubbles_EL.fpp:1345Fix →
5.0e-11_wp. Note: the source linter's d-literal regex ([0-9]d0) only catches...d0, so5.0d-11slips through. This is the onlyd-literal remaining insrc/. Output-neutral (same value).(b)
integer(wp)loop counter —src/simulation/m_bubbles_EE.fpp:73wpis a real kind; using it as an integer kind is wrong/non-portable. Fix →integer. Only occurrence insrc/. Output-neutral.(c) Bare literals missing
_wp(add_wp, value unchanged):src/common/m_constants.fpp:38—capillary_cutoff = 1.e-6→1.e-6_wpsrc/simulation/m_ibm.fpp:1137—0.4*patch_ib(...)%mass...→0.4_wp*src/simulation/m_acoustic_src.fpp:351—1/foc_length(ai)→1._wp/...src/simulation/m_ib_patches.fpp:603-604—-0.5*length(...)/0.5*length(...)→0.5_wpsrc/simulation/m_ib_patches.fpp:773-774,:854-855—1e12/-1e12→1e12_wp/-1e12_wpsrc/simulation/m_compute_levelset.fpp:151,157,241—dist_vec(3) = 0→0._wpsrc/simulation/m_compute_levelset.fpp:514,555-566— integer array literals(/1, 0, 0/)etc. assigned to real vectors → real literals(d) HardcodedIC — golden-gated, NOT output-neutral:
src/common/include/1dHardcodedIC.fpp:24,29—1 + 0.2*sin(5*x_cc(i))etc. (bare0.2,5default-real literals)These compile into pre_process initial conditions used by case-optimization tests. Adding
_wpis value-neutral in exact arithmetic, but because these are golden-gated pre_process outputs the change may need./mfc.sh test --generate --only <affected>if rounding shifts any digit. Flag for test regen — do not assume neutral.Why it matters:
d-literals and bare-real literals break single/mixed-precision builds (--single,--mixed) — a1.e-6literal isreal32regardless ofwp, silently changing results in mixed mode.integer(wp)is outright type-incorrect.Filed from a repo-wide code-cleanliness review; locations verified against
master@40dde5e.Code references
src/simulation/m_bubbles_EL.fpp:1345— 5.0d-11 d-literalsrc/simulation/m_bubbles_EE.fpp:73— integer(wp) loop countersrc/common/m_constants.fpp:38— 1.e-6 missing _wpsrc/simulation/m_ib_patches.fpp:603-604— 0.5* missing _wpsrc/simulation/m_compute_levelset.fpp:514— integer array literal to realsrc/common/include/1dHardcodedIC.fpp:24— bare literals (golden-gated)