Fortran #5462: Global name too long

[gspetro-NOAA]

Description

In WM PR 3174, RT logs showed no warnings or remarks for most compiles. However, when we turned on WARN_AS_ERROR in the PR, it produced several "global name too long" warnings, mostly from CCPP. For example:

/scratch4/NAGAPE/epic/Gillian.Petro/stmp/RT_RUNDIRS/Gillian.Petro/FV3_RT/rt_4056323/compile_s2swa_32bit_oneapi/build_fv3_s2swa_32bit_oneapi/UFSATM/ccpp/ccpp/ccpp_FV3_GFS_v17_coupled_p8_ugwpv1_cap.F90(233): error #5462: Global name too long, shortened from: ccpp_fv3_gfs_v17_coupled_p8_ugwpv1_cap_mp_FV3_GFS_V17_COUPLED_P8_UGWPV1_PHYSICS_TIMESTEP_INIT to: p_fv3_gfs_v17_coupled_p8_ugwpv1_cap_mp_FV3_GFS_V17_COUPLED_P8_UGWPV1_PHYSICS_TIMESTEP_INIT
  subroutine FV3_GFS_v17_coupled_p8_ugwpv1_physics_timestep_init( &
-------------^
/scratch4/NAGAPE/epic/Gillian.Petro/stmp/RT_RUNDIRS/Gillian.Petro/FV3_RT/rt_4056323/compile_s2swa_32bit_oneapi/build_fv3_s2swa_32bit_oneapi/UFSATM/ccpp/ccpp/ccpp_FV3_GFS_v17_coupled_p8_ugwpv1_cap.F90(527): error #5462: Global name too long, shortened from: ccpp_fv3_gfs_v17_coupled_p8_ugwpv1_cap_mp_FV3_GFS_V17_COUPLED_P8_UGWPV1_PHYSICS_TIMESTEP_FINAL to: _fv3_gfs_v17_coupled_p8_ugwpv1_cap_mp_FV3_GFS_V17_COUPLED_P8_UGWPV1_PHYSICS_TIMESTEP_FINAL
  subroutine FV3_GFS_v17_coupled_p8_ugwpv1_physics_timestep_final( &
-------------^

It seems unnecessary for the names to be so long, since there is duplicate info. For example, "ccpp_fv3_gfs_v17_coupled_p8_ugwpv1" is repeated twice in the name. Even though error 5462 is disabled in ufs-weather-model/cmake/IntelLLVM.cmake, when WARN_AS_ERROR is on, the out file shows Cannot disable Fortran error message 5462 and compilation fails.

Steps to Reproduce

Provide the tag or hash of the CCPP Framework used to reproduce the bug: c4b7d9a (I think this corresponds to tag capgen-1.0.0-pre.

Have you make any modifications to the CCPP Framework code? No.

1. Clone WM PR 3174: git clone --recursive -b feature/ss2.x https://github.com/gspetro-NOAA/ufs-weather-model.git 3174
2. Run any of these compiles from the ufs-weather-model/tests directory:
   • s2swa_32bit_oneapi
   • s2sw_32bit_pdlib_oneapi
   • s2sw_oneapi
   • s2swl_oneapi
   • s2s_aoflux_oneapi
   • s2sw_pdlib_oneapi
   • csawmg_oneapi
   • wam_oneapi
   • hafsw_oneapi
   • hafs_mom6w_oneapi
   • hafs_all_oneapi
   • atm_ds2s_docn_pcice_oneapi
   • atmw_oneapi
   • atmaero_oneapi
   • atmaq_oneapi
3. View the err and out files to see the details of the errors/warnings/remarks.

Additional Context

Please provide any relevant information about your setup. This is important in case the issue is not reproducible except for under certain conditions.

• Machines: Ursa, Hercules, Orion, and Gaea C6
• Compiler: OneAPI (LLVM)
• Suite Definition File or Scheme: Set via COMPILE line in rt.conf; differs based on the compile job.
• Reference other issues or PRs in other repositories that this is related to, and how they are related: There is a whole host of sub-PRs under WM PR 3174, as well as related issues in each repo. See the main PR for the links.

Output

Please include any relevant log files, screenshots or other output here.

Run directories:

• Ursa: /scratch4/NAGAPE/epic/Gillian.Petro/stmp/RT_RUNDIRS/Gillian.Petro/FV3_RT/rt_4056323
• Hercules: /work2/noaa/epic/gpetro/hercules/RTs/ufs-wm/stmp/gpetro/FV3_RT/rt_3294532

Test directories:

• Ursa: /scratch3/NAGAPE/epic/Gillian.Petro/ursa/RTs/ufs-wm/pretests/3174/tests
• Hercules: /work2/noaa/epic/gpetro/hercules/RTs/ufs-wm/pretests/3174/tests

[climbfuji]

Thanks for the bug report. I assigned this to me.

The Fortran 2003 standard defines a maximum length of 63 characters for most syntax elements — including subroutine names, function names, module names, and variable names. The subroutine your compiler is tripping over is

subroutine FV3_GFS_v17_coupled_p8_ugwpv1_physics_timestep_init

or 52 characters in length - less than the upper limit of 63 characters. ccpp-framework has a built-in mechanism to shorten names longer than 63 characters by cutting it at 63 minus hash length and then appending a hash to avoid duplicates. This mechanism doesn't trigger here, because the subroutine name is only 52 characters in length.

What the compiler really complains about is:

error #5462: Global name too long, shortened from: ccpp_fv3_gfs_v17_coupled_p8_ugwpv1_cap_mp_FV3_GFS_V17_COUPLED_P8_UGWPV1_PHYSICS_TIMESTEP_INIT to: p_fv3_gfs_v17_coupled_p8_ugwpv1_cap_mp_FV3_GFS_V17_COUPLED_P8_UGWPV1_PHYSICS_TIMESTEP_INIT

or, in other words, the global name it composes from the module name and the subroutine name. The length is 93 characters, which is then truncated to 90 characters.

That's a different story, and I don't know yet what the Fortran standard says about this, if anything.

I'll look into it further, but this could turn out to be a compiler problem that the CCPP framework shouldn't have to fix - i.e. an invitation for fixing all sorts of compiler issues in code that is completely legal per Fortran standard.

I'll let you know what I find.

[climbfuji]

Follow-up to my earlier comment. Short version: the code is standard-conforming, but we should still fix it, because capgen v1 made this worse than prebuild.

What the standard says. Fortran 2003-2018 cap names at 63 characters — module names, procedure names, and so on. Ours are fine (38 and 51). What Intel rejects is the mangled linker symbol mp, an implementation artifact the standard says nothing about. Intel truncates those at 90 characters. So this is an ifx limitation, not a standards violation.

But it is a regression on our side. For FV3_GFS_v17_coupled_p8_ugwpv1:

generator	subroutine	mangled global
ccpp-prebuild	..._tsinit_cap / ..._tsfinal_cap	82 / 83 ✅
capgen v1	..._physics_timestep_init / _final	93 / 94 ❌

ccpp-prebuild abbreviated the phase (tsinit, tsfinal); capgen v1 spells out _physics_timestep_init. That's 11 characters, dropping the effective ceiling on suite-name length from 32 to 27. This suite is 29 - it fit before but no longer does.

Note, there is no correctness risk. Intel truncates from the left, and the surviving names stay unique across every symbol this suite emits. It is a diagnostic only and so builds without WARN_AS_ERROR are unaffected.

Fix. @gspetro-NOAA's observation is right: the suite name appears in both the module and the subroutine, and the module procedure is already scoped by its module. Removing that duplication raises the ceiling to roughly 49 characters, comfortably above anything in the UFS suite list. The implementation must be done carefully: two of the generated caps use-associate names that would otherwise clash (from <module-name> import <phase>), and the trace and error strings have to keep the fully-qualified form. Thus, not a one-liner, but manageable. The host-facing API is unchanged: call ccpp_physics_<phase> from <host>_ccpp_cap stays as it is.

I'll create a PR shortly.

[climbfuji]

@gspetro-NOAA Please have a look at #787 - can you update the ccpp-framework submodule in your UFS branch to https://github.com/climbfuji/ccpp-framework/tree/feature/bugfix_intel_symbol_mangling_length and test?

[gspetro-NOAA]

On the one compile I ran (compile_s2sw_32bit_pdlib_oneapi), it fixed one of the two 5462 errors. You can see my rundir here: /scratch4/NAGAPE/epic/Gillian.Petro/stmp/RT_RUNDIRS/Gillian.Petro/FV3_RT/rt_2486280/compile_s2sw_32bit_pdlib_oneapi. I can test on more compile jobs if you'd like but wanted to be sure it worked first. Seems like it does, but not 100%?

[climbfuji]

On the one compile I ran (compile_s2sw_32bit_pdlib_oneapi), it fixed one of the two 5462 errors. You can see my rundir here: /scratch4/NAGAPE/epic/Gillian.Petro/stmp/RT_RUNDIRS/Gillian.Petro/FV3_RT/rt_2486280/compile_s2sw_32bit_pdlib_oneapi. I can test on more compile jobs if you'd like but wanted to be sure it worked first. Seems like it does, but not 100%?

Please post any relevant output here so that I can look at it. Thanks.

[gspetro-NOAA]

On the one compile I ran (compile_s2sw_32bit_pdlib_oneapi), it fixed one of the two 5462 errors. You can see my rundir here: /scratch4/NAGAPE/epic/Gillian.Petro/stmp/RT_RUNDIRS/Gillian.Petro/FV3_RT/rt_2486280/compile_s2sw_32bit_pdlib_oneapi. I can test on more compile jobs if you'd like but wanted to be sure it worked first. Seems like it does, but not 100%?

Please post any relevant output here so that I can look at it. Thanks.

In the new err file, there's:

Found Python: /contrib/spack-stack/spack-stack-2.1.1/envs/ue-oneapi-2025.3.1/install/none/none/python-venv-1.0-4zzat5x/bin/python3.11
INFO/scratch3/NAGAPE/epic/Gillian.Petro/ursa/RTs/ufs-wm/pretests/3174-ccpp-framework-bugfix/UFSATM/ccpp/data/CCPP_typedefs.meta;/scratch3/NAGAPE/epic/Gillian.Petro/ursa/RTs/ufs-wm/pretests/3174-ccpp-framework-bugfix/UFSATM/ccpp/data/GFS_typedefs.meta;/scratch3/NAGAPE/epic/Gillian.Petro/ursa/RTs/ufs-wm/pretests/3174-ccpp-framework-bugfix/UFSATM/ccpp/CCPP_driver.meta;/scratch3/NAGAPE/epic/Gillian.Petro/ursa/RTs/ufs-wm/pretests/3174-ccpp-framework-bugfix/UFSATM/ccpp/data/CCPP_data.meta;physics/physics/hooks/physcons.meta --> /scratch3/NAGAPE/epic/Gillian.Petro/ursa/RTs/ufs-wm/pretests/3174-ccpp-framework-bugfix/UFSATM/ccpp/data/CCPP_typedefs.F90;/scratch3/NAGAPE/epic/Gillian.Petro/ursa/RTs/ufs-wm/pretests/3174-ccpp-framework-bugfix/UFSATM/ccpp/data/GFS_typedefs.F90;/scratch3/NAGAPE/epic/Gillian.Petro/ursa/RTs/ufs-wm/pretests/3174-ccpp-framework-bugfix/UFSATM/ccpp/CCPP_driver.F90;/scratch3/NAGAPE/epic/Gillian.Petro/ursa/RTs/ufs-wm/pretests/3174-ccpp-framework-bugfix/UFSATM/ccpp/data/CCPP_data.F90;/scratch3/NAGAPE/epic/Gillian.Petro/ursa/RTs/ufs-wm/pretests/3174-ccpp-framework-bugfix/UFSATM/ccpp/physics/physics/hooks/physcons.F90
+ OMP_NUM_THREADS=1
+ make -j 8 VERBOSE=1
ifx: command line warning #10121: overriding '-fiopenmp' with '-qno-openmp'
ifx: command line warning #10121: overriding '-fiopenmp' with '-qno-openmp'
ifx: command line warning #10121: overriding '-fiopenmp' with '-qno-openmp'
ifx: command line warning #10121: overriding '-fiopenmp' with '-qno-openmp'
ifx: command line warning #10121: overriding '-fiopenmp' with '-qno-openmp'
/scratch3/NAGAPE/epic/Gillian.Petro/ursa/RTs/ufs-wm/pretests/3174-ccpp-framework-bugfix/UFSATM/ccpp/physics/physics/SFC_Models/Land/Noahmp/module_sf_noahmplsm.F90(9997): remark #7713: This statement function has not been used.   [R]
  real (kind=kind_phys) :: r,x
---------------------------^
/scratch3/NAGAPE/epic/Gillian.Petro/ursa/RTs/ufs-wm/pretests/3174-ccpp-framework-bugfix/UFSATM/fv3/stochastic_physics/stochastic_physics_wrapper.F90(554): error #5462: Global name too long, shortened from: stochastic_physics_wrapper_modstochastic_physics_wrapper_mp_TRANSFER_FIELD_TO_STOCHASTICS_3D to: ochastic_physics_wrapper_modstochastic_physics_wrapper_mp_TRANSFER_FIELD_TO_STOCHASTICS_3D
    subroutine transfer_field_to_stochastics_3d(blksz, data_in, data_out)
---------------^
compilation aborted for /scratch3/NAGAPE/epic/Gillian.Petro/ursa/RTs/ufs-wm/pretests/3174-ccpp-framework-bugfix/UFSATM/fv3/stochastic_physics/stochastic_physics_wrapper.F90 (code 1)
make[2]: *** [UFSATM/CMakeFiles/ufsatm_fv3.dir/build.make:143: UFSATM/CMakeFiles/ufsatm_fv3.dir/fv3/stochastic_physics/stochastic_physics_wrapper.F90.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [CMakeFiles/Makefile2:610: UFSATM/CMakeFiles/ufsatm_fv3.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
make: *** [Makefile:136: all] Error 2

In the previous compile err file, the main difference was

/scratch4/NAGAPE/epic/Gillian.Petro/stmp/RT_RUNDIRS/Gillian.Petro/FV3_RT/rt_4056323/compile_s2sw_32bit_pdlib_oneapi/build_fv3_s2sw_32bit_pdlib_oneapi/UFSATM/ccpp/ccpp/ccpp_FV3_GFS_v17_coupled_p8_ugwpv1_cap.F90(233): error #5462: Global name too long, shortened from: ccpp_fv3_gfs_v17_coupled_p8_ugwpv1_cap_mp_FV3_GFS_V17_COUPLED_P8_UGWPV1_PHYSICS_TIMESTEP_INIT to: p_fv3_gfs_v17_coupled_p8_ugwpv1_cap_mp_FV3_GFS_V17_COUPLED_P8_UGWPV1_PHYSICS_TIMESTEP_INIT
  subroutine FV3_GFS_v17_coupled_p8_ugwpv1_physics_timestep_init( &
-------------^
/scratch4/NAGAPE/epic/Gillian.Petro/stmp/RT_RUNDIRS/Gillian.Petro/FV3_RT/rt_4056323/compile_s2sw_32bit_pdlib_oneapi/build_fv3_s2sw_32bit_pdlib_oneapi/UFSATM/ccpp/ccpp/ccpp_FV3_GFS_v17_coupled_p8_ugwpv1_cap.F90(527): error #5462: Global name too long, shortened from: ccpp_fv3_gfs_v17_coupled_p8_ugwpv1_cap_mp_FV3_GFS_V17_COUPLED_P8_UGWPV1_PHYSICS_TIMESTEP_FINAL to: _fv3_gfs_v17_coupled_p8_ugwpv1_cap_mp_FV3_GFS_V17_COUPLED_P8_UGWPV1_PHYSICS_TIMESTEP_FINAL
  subroutine FV3_GFS_v17_coupled_p8_ugwpv1_physics_timestep_final( &
-------------^

[climbfuji]

The new/remaining error has nothing to do with CCPP - it is from UFSATM/fv3/stochastic_physics/stochastic_physics_wrapper.F90 as the log shows. That's an issue the UFSATM maintainers need to fix.

The warning for noahmplsm is something for the ccpp-physics repo - can fix in the ufs/dev branch in ufs-community.

As far as ccpp-framework goes, it looks like we're golden.

[gspetro-NOAA]

Thanks! Yeah, looks like I may have to hunt down devs for other repos (for example, I recall a 5462 for MOM6 in another compile) or find a way for WARN_AS_ERROR to actually ignore our disabled warnings. 🤔 Thanks for this work tho!