32-bit physics with FV3_RAP#534
Conversation
…l not yet tested)
|
@SamuelTrahanNOAA For the overloading capability, would you like to try the Fortran polymorphic class? Please see example: |
I think the resulting code would be just as complex, and would use features many developers don't know. If Fortran had templates or generics, I would use that, but it doesn't. |
f599ef9 to
9caaf80
Compare
* Remove FMS git submodule * Update module files and top-level CMakeLists.txt to use fms module (library) built by hpc-stack. * Update ci for fms library NOAA-EMC#575 (NCAR#13) Co-authored-by: Minsuk Ji <57227195+MinsukJi-NOAA@users.noreply.github.com>
…al component")
…ully get all suites to compile)
…atm into working_32bit
… is out-of-sync with the NOAA-EMC fv3atm
I see no obvious "best way" of cleaning up this code, so I made an issue here: We can discuss a better option in that issue. |
|
@SamuelTrahanNOAA so its this pr's turn to update and merge. |
|
The atmos_cubed_sphere and ccpp/physics point to the authoritative branches now. This PR is ready for final review and merge. |
|
I need a second review before this can be merged. |
This adds support for 32-bit physics to the FV3, based on prior work on the Neptune model. The 64-bit physics should not change results. Presently, the 32-bit physics are incompatible with MOM6 because it has conflicting stochastic_physics precision requirements, so MOM6-coupled configurations must use 64-bit physics.
Issues
ufs-community/ufs-weather-model#1288
Dependencies
NCAR/ccpp-physics#930
NOAA-GFDL/GFDL_atmos_cubed_sphere#193
earth-system-radiation/rte-rrtmgp#180this was already merged