ufs-weather-model icon indicating copy to clipboard operation
ufs-weather-model copied to clipboard

MOM6 and FV3 have conflicting precision requirements when FV3 is built with 32-bit physics

Open SamuelTrahanNOAA opened this issue 2 years ago • 4 comments

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:

  1. Change the MOM6 to use a type provided by stochastic physics
  2. 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:

  1. Wait for #1215 to be merged.
  2. Try to build one of the coupled tests with 32-bit physics (-DCCPP_32BIT=Y)
  3. 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 avatar Jun 24 '22 12:06 SamuelTrahanNOAA

@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?

junwang-noaa avatar Jun 30 '22 02:06 junwang-noaa

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:

  1. kind_real (or similar) inside stochastic_physics for most calculations
  2. kind_atmos for the atmosphere front-ends
  3. 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.

SamuelTrahanNOAA avatar Jun 30 '22 15:06 SamuelTrahanNOAA

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 avatar Jun 30 '22 15:06 SamuelTrahanNOAA

@SamuelTrahanNOAA I will look into making the changes that are consistent with option (2)

pjpegion avatar Jul 19 '22 14:07 pjpegion

@pjpegion Can this issue be closed?

DeniseWorthen avatar Jan 11 '23 15:01 DeniseWorthen

I have not had time to fix this

pjpegion avatar Jan 11 '23 15:01 pjpegion

@pjpegion Thanks, just trying to clean up issues.

DeniseWorthen avatar Jan 11 '23 15:01 DeniseWorthen

@SamuelTrahanNOAA Is this issue addressed?

junwang-noaa avatar Jul 03 '23 14:07 junwang-noaa

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.

SamuelTrahanNOAA avatar Jul 03 '23 14:07 SamuelTrahanNOAA