search

ai2cm / fv3gfs-fortran

FV3GFS Fortran for internal development at AI2
Other
6 stars 9 forks source link

Should the Python wrapper orient all 3D variables the same way in the vertical? #347

Open spencerkclark opened 1 year ago

spencerkclark commented 1 year ago

The Python wrapper currently enables getting and setting a few 3D variables in the Stateout container. Since these 3D variables come from the physics side of the model, they are oriented oppositely to the dynamical core 3D variables in the vertical (in the physics the lowest model level is at vertical index 0, while in the dynamical core the uppermost model level is at vertical index 0).

This difference can lead to bugs, especially when trying to update physics fields based on fields from the dynamical core (or vice versa). In principle it seems like it would be possible for the Python wrapper to handle this dimension flipping automatically (both in the getting and setting stages). I could imagine adding an optional flag to variables in the *properties.json files that would trigger this behavior (or perhaps automatically flipping any 3D variable in the physics_properties.json file).

The main argument against doing that I can imagine is that it would technically not be exactly true to the state of the fortran model. Another argument is that it would potentially be a breaking change to anyone who was using these variables before, but I'm not sure how many users there are, if any, outside of us.

cc: @oliverwm1 @mcgibbon

spencerkclark commented 1 year ago

@mcgibbon is on board with this assuming it doesn't break anything else we do currently.

@frodre I recall you mentioning you ran into this issue some in the microphysics emulation project (at least in that you had to deal with the fact that the vertical orientation is different in the physics than in the dynamics). Do you rely on getting / setting 3D variables from the physics in your work, and would a change like this be disruptive?

frodre commented 1 year ago

@spencerkclark No the change would not be disruptive on the microphysics emulation side. All of the state update handling is done in our callpyfort hooks instead of the wrapper. We also don't use any of the wrapper's physics fields in our analysis as far as I'm aware.

spencerkclark commented 1 year ago

Awesome -- thanks for confirming that @frodre, so we should be clear to go here.