Update main from develop 2025/07/24 --> 2025/08/21

[climbfuji]

All in the title.

Testing (cleared the board after merging #669 into develop and then into this branch/PR):

• UFS (see discussion below and in particular Update main from develop 2025/07/24 --> 2025/08/21 #668 (comment))
• SIMA/CESM
• NEPTUNE (GitHub actions: 287 successful and 230 skipped checks, as expected)
• SCM
• CI

User interface changes?: No/Yes

Fixes: Nothing.

Testing: See above

[peverwhee]

SIMA tests pass.

Also I'm going to add Fixes: Nothing to my resume.

[climbfuji]

Last update for today. There are at least two issues:

1. Lowercasing of certain names in the new capgen metadata parser. I believe we can work around this without too much effort by requiring certain fields in ccpp_prebuild_config to be all lowercase.
2. The information passed back from the capgen metadata parser to prebuild is (or at least seems to be) very different. This has to do with how the variables are decomposed (there was a PR for capgen to pass individual variables and not the parent DDTs or vice versa?). Debugging output from ccpp_prebuild (at the time of writing the caps, i.e. AFTER parsing the metadata with capgen, passing it to prebuild, and analyzing it), one example variable:

OLD = GOOD CODE

DEBUG: Requested variable surface_air_pressure_two_timesteps_back in
    MODULE_GFS_rad_time_vary SCHEME_GFS_rad_time_vary SUBROUTINE_GFS_rad_time_vary_timestep_init
    matched to target GFS_Tbd(cdata%ccpp_instance)%phy_f2d(:,GFS_Control(cdata%ccpp_instance)%nps2delt)
    in module GFS_typedefs

NEW = BROKEN CODE

DEBUG: Requested variable surface_air_pressure_two_timesteps_back in 
    MODULE_GFS_rad_time_vary SCHEME_GFS_rad_time_vary SUBROUTINE_GFS_rad_time_vary_timestep_init
    matched to target phy_f2d(:, index_of_surface_air_pressure_two_timesteps_back_in_xyz_dimensioned_tracer_array)
    in module GFS_typedefs

Obviously, there are two issues: (a) the information on where to find this variable in the host model is no longer complete; and (b) instead of local names as known to the host model, we have standard names for the indices, but local names for the actual variable. It is not clear to me immediately what exactly triggered this change, and the size of the pull request doesn't make it easier. Maybe some of it is also related to the lowercasing?

[climbfuji]

After much debugging, I got it to complete the call to ccpp_prebuild.py and to compile NEPTUNE. Just need to sort out a few remaining quirks with uppercase vs lowercase suite names.

[dustinswales]

@climbfuji The ccpp_prebuild step is failing in the UFS when I switch to this branch:

parse_source.CCPPError: Invalid horizontal dimension, 'horizontal_loop_extent', at CCPP_typedefs.meta:13
Invalid horizontal dimension, 'horizontal_loop_extent', at CCPP_typedefs.meta:20
Invalid horizontal dimension, 'horizontal_loop_extent', at CCPP_typedefs.meta:27
Invalid horizontal dimension, 'horizontal_loop_extent', at CCPP_typedefs.meta:34
Invalid horizontal dimension, 'horizontal_loop_extent', at CCPP_typedefs.meta:41
Invalid horizontal dimension, 'horizontal_loop_extent', at CCPP_typedefs.meta:48
Invalid horizontal dimension, 'horizontal_loop_extent', at CCPP_typedefs.meta:55
Invalid horizontal dimension, 'horizontal_loop_extent', at CCPP_typedefs.meta:62
Invalid horizontal dimension, 'horizontal_loop_extent', at CCPP_typedefs.meta:69
Invalid horizontal dimension, 'horizontal_loop_extent', at CCPP_typedefs.meta:76
Invalid horizontal dimension, 'horizontal_loop_extent', at CCPP_typedefs.meta:83
Invalid horizontal dimension, 'horizontal_loop_extent', at CCPP_typedefs.meta:90
Invalid horizontal dimension, 'horizontal_loop_extent', at CCPP_typedefs.meta:97
Invalid horizontal dimension, 'horizontal_loop_extent', at CCPP_typedefs.meta:104
Invalid horizontal dimension, 'horizontal_loop_extent', at CCPP_typedefs.meta:112
Invalid horizontal dimension, 'horizontal_loop_extent', at CCPP_typedefs.meta:119
Invalid horizontal dimension, 'horizontal_loop_extent', at CCPP_typedefs.meta:126
Invalid horizontal dimension, 'horizontal_loop_extent', at CCPP_typedefs.meta:133
Invalid horizontal dimension, 'horizontal_loop_extent', at CCPP_typedefs.meta:140
Invalid horizontal dimension, 'horizontal_loop_extent', at CCPP_typedefs.meta:147
Invalid horizontal dimension, 'horizontal_loop_extent', at CCPP_typedefs.meta:154
Invalid horizontal dimension, 'horizontal_loop_extent', at CCPP_typedefs.meta:161
Invalid horizontal dimension, 'horizontal_loop_extent', at CCPP_typedefs.meta:168
Invalid horizontal dimension, 'horizontal_loop_extent', at CCPP_typedefs.meta:175
Invalid horizontal dimension, 'horizontal_loop_extent', at CCPP_typedefs.meta:182
Invalid horizontal dimension, 'horizontal_loop_extent', at CCPP_typedefs.meta:189
Invalid horizontal dimension, 'horizontal_loop_extent', at CCPP_typedefs.meta:196

This is a new one for me. I can only find references to these error messages in the unit-testing code, which shouldn't(?) be triggered during the Cmake step. Right? (And if so, is this new? And why is it breaking?)
@mwaxmonsky @peverwhee Any ideas?

[mwaxmonsky]

@climbfuji The ccpp_prebuild step is failing in the UFS when I switch to this branch:

parse_source.CCPPError: Invalid horizontal dimension, 'horizontal_loop_extent', at CCPP_typedefs.meta:13 Invalid horizontal dimension, 'horizontal_loop_extent', at CCPP_typedefs.meta:20 Invalid horizontal dimension, 'horizontal_loop_extent', at CCPP_typedefs.meta:27 Invalid horizontal dimension, 'horizontal_loop_extent', at CCPP_typedefs.meta:34 Invalid horizontal dimension, 'horizontal_loop_extent', at CCPP_typedefs.meta:41 Invalid horizontal dimension, 'horizontal_loop_extent', at CCPP_typedefs.meta:48 Invalid horizontal dimension, 'horizontal_loop_extent', at CCPP_typedefs.meta:55 Invalid horizontal dimension, 'horizontal_loop_extent', at CCPP_typedefs.meta:62 Invalid horizontal dimension, 'horizontal_loop_extent', at CCPP_typedefs.meta:69 Invalid horizontal dimension, 'horizontal_loop_extent', at CCPP_typedefs.meta:76 Invalid horizontal dimension, 'horizontal_loop_extent', at CCPP_typedefs.meta:83 Invalid horizontal dimension, 'horizontal_loop_extent', at CCPP_typedefs.meta:90 Invalid horizontal dimension, 'horizontal_loop_extent', at CCPP_typedefs.meta:97 Invalid horizontal dimension, 'horizontal_loop_extent', at CCPP_typedefs.meta:104 Invalid horizontal dimension, 'horizontal_loop_extent', at CCPP_typedefs.meta:112 Invalid horizontal dimension, 'horizontal_loop_extent', at CCPP_typedefs.meta:119 Invalid horizontal dimension, 'horizontal_loop_extent', at CCPP_typedefs.meta:126 Invalid horizontal dimension, 'horizontal_loop_extent', at CCPP_typedefs.meta:133 Invalid horizontal dimension, 'horizontal_loop_extent', at CCPP_typedefs.meta:140 Invalid horizontal dimension, 'horizontal_loop_extent', at CCPP_typedefs.meta:147 Invalid horizontal dimension, 'horizontal_loop_extent', at CCPP_typedefs.meta:154 Invalid horizontal dimension, 'horizontal_loop_extent', at CCPP_typedefs.meta:161 Invalid horizontal dimension, 'horizontal_loop_extent', at CCPP_typedefs.meta:168 Invalid horizontal dimension, 'horizontal_loop_extent', at CCPP_typedefs.meta:175 Invalid horizontal dimension, 'horizontal_loop_extent', at CCPP_typedefs.meta:182 Invalid horizontal dimension, 'horizontal_loop_extent', at CCPP_typedefs.meta:189 Invalid horizontal dimension, 'horizontal_loop_extent', at CCPP_typedefs.meta:196

This is a new one for me. I can only find references to these error messages in the unit-testing code, which shouldn't(?) be triggered during the Cmake step. Right? (And if so, is this new? And why is it breaking?) @mwaxmonsky @peverwhee Any ideas?

These might be coming from the CMake changes but I'd be very concerned since I don't see CCPP_typedefs.meta in the framework repo and that string is only hardcoded in the unit-tests directory, not the regression tests. Unless there's something I missed (definitely possible since there was a lot going on!), the unit-tests directory shouldn't be included by CMake.

The only other place that I can see after a cursory glance of the error handler is on line 138 of parse_source.py: message = "Invalid {}, '{}'{}".format(token_type, token, cstr) that looks like this might be flagging something. The cstr get's converted to 'at ' based on the context so this might be a legitimate error coming from the framework.

So two things come to mind right away:

1. Could you post the CMake output from the messages at the top of the parent level CMake that list the different options? That would help tell us if the tests are being included at all.
2. I'd need to see the stack trace from where the exception is raised to know for sure where the error comes from but we don't track that. If you could try the traceback module to see if this is where the message is coming from and print the trace to stdout, that would help figure out what the path to the error is if this is where its coming from (https://docs.python.org/3/library/traceback.html#examples-of-using-the-module-level-functions):

import traceback
...
traceback.print_stack()

[peverwhee]

@dustinswales I think that's due to #659

I'm guessing those horizontal_loop_extents should be horizontal_dimensions

[climbfuji]

@peverwhee Is right, see https://github.com/NOAA-EMC/fv3atm/blob/e5b040cca39537499130260e0b65425543416f03/ccpp/data/CCPP_typedefs.meta

On the UFS side, with #669 pulled into #668, you will need to make at least two other changes:

1. Declare the full arrays phy_f2d and phy_f3d (not just the "slices" of it) in the GFS_typedefs.F90 metadata. capgen wants that now.
2. Update the lower and upper bounds for the Noah LSM soil dimension (need to be variables, not hard-coded integers).

[dustinswales]

Thanks @peverwhee and @climbfuji!
I'll make those changes and try again.

[climbfuji]

@peverwhee @dustinswales @mkavulich @grantfirl I pulled develop into this branch on Aug 21 so that it now contains the bug fixes from #669. We should all retest with this PR before we merge this into develop (sorry @peverwhee if you have to run the tests twice).

[peverwhee]

sima tests pass!

[mkavulich]

Just checking in, it looks like SIMA and NEPTUNE regtests have passed, we're just waiting on UFS now?

[dustinswales]

@mkavulich This is correct.
All UFS RTs are b4b except for one, the rrtmgp test.
I'm not sure what's going on and I apologize for this holding up the framework PRs.
@climbfuji @peverwhee I'm not sure of the best way forward? I'm going to see if I can get some help debugging this, but I fear that all roads lead to me with rrtmgp in the CCPP :(

[dustinswales]

All UWM tests pass except single test with rrtmgp.
Bug in rrtmgp code will be addressed at a later time.

[climbfuji]

Background on the RRTMGP b4b failure in the UFS: We tracked this down to a bug in the memory handling on the UFS side. A variable used by RRTMGP (which is in the radiation group of the CCPP suite) is valid in the physics group of the suite only. The variable needs identified and then be moved from the interstitial DDT, that is non-persistent by definition, to a persistent DDT.

This confirms that the develop branch of ccpp-framework is good and that this PR can be merged.

[climbfuji]

@mkavulich Let's merge please if you are ok

[mkavulich]

Adding a third approval since Dom's implicit approval as the PR opener doesn't count