32-bit physics with FV3_RAP

[SamuelTrahanNOAA]

This adds support for 32-bit physics to the FV3, based on prior work on the Neptune model, without changing results of the 64-bit configuration. Presently, the 32-bit physics is incompatible with MOM6 because its precision requirements will conflict with the precision requirements of the atmosphere. That means MOM6-coupled configurations must use 64-bit physics.

These changes also refactor the real and integer kinds, cleaning them up a bit.

See the top-level PR here for details:

ufs-community/ufs-weather-model#1215

The issue for this is here:

ufs-community/ufs-weather-model#1288

[pjpegion]

I have not looked at the fv3_atm side yet. Will 32-bit stochastic physics work with 64-bit physics? If not, can you point me to a test case with 32-bit physics that I can try?

[SamuelTrahanNOAA]

I have not looked at the fv3_atm side yet. Will 32-bit stochastic physics work with 64-bit physics? If not, can you point me to a test case with 32-bit physics that I can try?

The subroutines in stochastic_physics that are called from FV3 have to use the same kinds as FV3 or the types won't match in the subroutine call. To avoid that necessity, we'd need a separate kind_fv3_phys, or something similar, that is used by the FV3 front-ends.

Any of the tests in rt.sh or rt_gnu.sh with "phy32" in their name are 32-bit physics tests. One of them, regional_spp_sppt_shum_skeb_dyn32_phy32 in rt.conf, uses stochastic_physics. I didn't include dyn64 phy32 version of it because it was far too slow to fit in the wallclock limits.

[pjpegion]

@SamuelTrahanNOAA understood and thanks.

[SamuelTrahanNOAA]

I made an issue for the mom6-fv3 precision conflict here:

ufs-community/ufs-weather-model#1289

[jkbk2004]

@pjpegion @SamuelTrahanNOAA ufs-wm pr1215 is ready.