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
I don't have an obvious suggestion so approving for now.
My guess is that this had to do with the fact that we previously computed momentum nudging tendencies in postphysics, but then didn't apply them until the next timestep due to the dycore/physics grid issue, so there was an intervening dycore call between computation and application. In that case it really makes sense to use the updated delp to compute the diagnostics, but we no longer do that since Spencer made it possible to set the A-grid winds (all tendencies are applied directly after postphysics computation). Sooo...I guess it is possible that we could merge the compute and apply postphysics steps, where it should be more obvious that the prescriber should produce an array of 0s for net_moistening. But that is a lot of refactoring and only tangential to this PR.
My other suggestion would be to disallow the possibility of the empty net_moistening data array coming from get_diagnostics. Empty data arrays seem like they are likely to cause trouble based on this experience. We could have some common method that steppers call to compute net_moistening that would fill it in with zeros as appropriate. Again outside of this PR though.
My guess is that this had to do with the fact that we previously computed momentum nudging tendencies in postphysics, but then didn't apply them until the next timestep due to the dycore/physics grid issue, so there was an intervening dycore call between computation and application. In that case it really makes sense to use the updated
delp
to compute the diagnostics, but we no longer do that since Spencer made it possible to set the A-grid winds (all tendencies are applied directly after postphysics computation). Sooo...I guess it is possible that we could merge the compute and apply postphysics steps, where it should be more obvious that the prescriber should produce an array of 0s fornet_moistening
. But that is a lot of refactoring and only tangential to this PR.My other suggestion would be to disallow the possibility of the empty
net_moistening
data array coming fromget_diagnostics
. Empty data arrays seem like they are likely to cause trouble based on this experience. We could have some common method that steppers call to computenet_moistening
that would fill it in with zeros as appropriate. Again outside of this PR though.Originally posted by @brianhenn in #2373 (comment)
The text was updated successfully, but these errors were encountered: