You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
@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?
@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.
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 thephysics_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
The text was updated successfully, but these errors were encountered: