ufs-weather-model
ufs-weather-model copied to clipboard
MOM6 and FV3 have conflicting precision requirements when FV3 is built with 32-bit physics
Description
When FV3 is built with 32-bit physics, MOM6 refuses to build because it expects stochastic physics to use 64-bit reals. Possible solutions are:
- Change the MOM6 to use a type provided by stochastic physics
- Change the stochastic physics to have a kind_ocn used for ocean-related routines. Internally in stochastic physics, everything will be 32 or 64 bits, depending on the stochastic physics build, but each model coupled with stochastic physics can send and receive data in their favorite precision.
I think the second option is the most flexible going forward.
To Reproduce:
- Wait for #1215 to be merged.
- Try to build one of the coupled tests with 32-bit physics (
-DCCPP_32BIT=Y
) - Witness build errors in MOM6
Additional context
https://github.com/ufs-community/ufs-weather-model/pull/1215 https://github.com/noaa-psd/stochastic_physics/pull/59 https://github.com/ufs-community/ufs-weather-model/issues/1288
@SamuelTrahanNOAA MOM6 has to run in 64 bit. So when you build fv3 physics, does the stochastic physics need to build with 32bit? Is that the issue in MOM6?
The way I set it up, the stochastic physics uses the kind_phys from fv3, except for calculations that must be double precision. That's because I didn't realize the ocean called stochastic_physics directly. The types should probably be rearranged like this:
- kind_real (or similar) inside stochastic_physics for most calculations
- kind_atmos for the atmosphere front-ends
- kind_ocean for the ocean front-ends
Then you'd add some c preprocessor magic in the front-ends to use temporary arrays if the type doesn't match, and no temporary arrays if it does match.
To clarify, stochastic_physics uses the same C preprocessor flag as FV3 (#ifdef CCPP_32BIT
) to decide on single vs. double precision, regardless of what MOM6 wants.
@SamuelTrahanNOAA I will look into making the changes that are consistent with option (2)
@pjpegion Can this issue be closed?
I have not had time to fix this
@pjpegion Thanks, just trying to clean up issues.
@SamuelTrahanNOAA Is this issue addressed?
No, it is not. I have an easy fix for it, but fixing the problem doesn't let MOM6 coupling run with 32-bit physics.