Necessary changes for HWRF physics (Ferrier-Aligo MP in dycore)

[climbfuji]

Description

See ufs-community/ufs-weather-model#223.

This PR contains two changes, one for avoiding crashes when the dycore debug option is turned on (in model/fv_dynamics.F90), and one for running microphysics with fewer tracers than in the input data set (in tools/external_ic.F90). This is required for Ferrier-Aligo microphysics.

Testing

See ufs-community/ufs-weather-model#223.

Dependencies

ufs-community/ufs-weather-model#223
NOAA-EMC/fv3atm#188
#43
NCAR/ccpp-physics#509

[bensonr]

What are the science impacts of taking ICs for a different number of hydrometeors / MP scheme and utilizing them in a reduced set? I assume the difference is in the number of water species for the F-A MP scheme. Has there been logic included to convert the missing water species to other precipitation types for the reduced set in F-A?

[climbfuji]

What are the science impacts of taking ICs for a different number of hydrometeors / MP scheme and utilizing them in a reduced set? I assume the difference is in the number of water species for the F-A MP scheme. Has there been logic included to convert the missing water species to other precipitation types for the reduced set in F-A?

These are good points. The HAFS group was experimenting with code that initializes the tracers based on what is available in the input files, but it hasn't been included in this PR. For the moment, we cannot conduct any physics testing with FA MP because the model crashes with a memory corruption after the first pass through the dycore. This problem occurred first when the GFDL_atmos_cubed_sphere repository was updated earlier this year (alongside with an FMS update, which was reverted as far as I remember). I did mention this a few times in the past, but we haven't gotten to the bottom of the problem yet.

Ideally, one would be running chgres to create the initial conditions for the MP scheme of choice, which would take care of adding the correct tracers (and doing any conversion of hydrometeors if needed). It is my understanding that the UFS_UTILS developers are working towards this. But independent of that we should be able to run the model with whatever MP scheme based on whatever hydrometeors are in the input data. Whether this is scientifically sound or not is a different question, but at least it allows one to conduct experiments and debug problems as the one above.

I had sent a question to the GFDL help desk last week whether removing the guard could be the reason for the stack corruption, but I haven't heard back yet. If the only reason the guard is there is to prevent physics inconsistencies, then I would be in favor of removing it or converting it into a warning. If, however, it has wider implications then we need to keep it and find another way to do our debugging and development with FA MP.

[climbfuji]

@bensonr did my reply to your comment make sense? Do you have further questions or concerns? We would like to merge the HWRF physics into the repositories today, if possible. Thanks!

[bensonr]

@climbfuji - I've checked with the extended team at GFDL and removal of the restriction is acceptable.

[climbfuji]

@climbfuji - I've checked with the extended team at GFDL and removal of the restriction is acceptable.

Thanks, @bensonr - appreciate your efforts!