Enable multiple schemes to use the same local name for different variables

[peverwhee]

Description

Right now, I am aware of two scenarios where two schemes having the same local name for different standard named variables causes an error. Ideally, the framework could handle these scenarios.

1. One variable has been promoted to the group level and one is at the scheme level
2. Both variables have been promoted to the group level

We should also test both variables at the scheme level.

Solution

Not exactly sure what the solution will look like!

[climbfuji]

At the framework meeting on Jan 2, 2025, we discussed this problem. These are actually two separate issues (and a non-issue) that need different solutions:

1. The host model defines two variables with the same name as part of two derived data types, classes etc. A mock example for the UFS would be GFS_diag%t2m and GFS_sfcprop%t2m. In ccpp-prebuild, this is not a problem, since prebuild always passes the entire DDT down to the group cap, and then passes the fields by reference (to the scheme if no local transformations are made, or to the transformation call). For the above example: call myscheme_run(t2=GFS_sfcprop%t2m,t2diag=GFS_diag%t2m). Since capgen passes the flat fields directly, we are left with two options:

   • Make it a requirement that all variable names defined by the host model (even if coming from different data structures) are unique. Not ideal.
   • Write the caps such that any variable coming from the host model in capgen has a local name that contains the encompassing data structures. For the above example, the cap would be using gfs_diag_t2m and gfs_sfcprop_t2m, and the top-level entry to CCPP from the host model would look like this:
     call ccpp-api(gfs_diag_t2m=GFS_diag%t2m,gfs_sfcprop_t2m=GFS_sfcprop%t2m)
     This is a better solution, but more work.

2. The auto-generated caps define two variables with the same local name, because there are two schemes A and B that both use this local name for different variables (i.e. standard names). This is entirely legal. There is no requirement that local names must uniquely correspond to standard names across schemes. But there is also no reason for the auto-generated caps to use the local names from schemes A and B in the auto-generated caps (since we pass variables explicitly to the schemes as shown above). ccpp-prebuild doesn't have this problem, because it uses random variable names in the auto-generated caps that are associated with a standard name: tmpvar_N where N is a running number. capgen could easily do the same. Alternatively, if more clarity (but potentially longer names) is dsired, one could prefix the local name for variables generated by capgen in the auto-generated caps with the scheme name: A_t2m and B_t2m.

3. The non-issue is the fact that two schemes A and B that both use this local name for different variables (i.e. standard names). This is allowed as discussed above.

[dustinswales]

@climbfuji After some digging, I'm not sure if this is an issue?

There are instances in the GFS v16 physics where different schemes have different arguments (standard_name), but use the same local name.
For example,
GFS_surface_composites_post.F90 uses cmm as the local_name for standard_name = surface_drag_wind_speed_for_momentum_in_air.
sfc_sice.f uses cmm as the local_name for standard_name = surface_drag_wind_speed_for_momentum_in_air_over_ice

Here is the auto-generated call to GFS_surface_composites_post_run from Prebuild:

And from Capgen:
Group_CAP (call to scheme):

Host_CAP (call to group cap):

For this scenario there are both (1) same local name in different data containers and (2) same local name in different schemes with different standard_names.
The autogenerated caps look correct in Capgen, the only difference being the lack of data blocking.

[climbfuji]

We'll need to wait until we hear from @peverwhee about the issue in CESM.