-
Notifications
You must be signed in to change notification settings - Fork 435
EAMxx: fix bugs related to ZonalMean diagnostic #7515
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
The last bin must also contain the upper bound
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to me! I did indeed neglect to consider when a column would have a lat value exactly at the poles when deciding a bin would be "open" at the upper bound. The same issue is present in #7481, although it will manifest in a different way (namely that the column at the pole will be ignored)... so I'm glad you caught this now!
As far as the conflict with #7481, my vote is to merge this PR as-is to address the bug while #7481 is reviewed.
The failures in xyz_run_and_cmp are unrelated, and currently under investigation separately. I am going to merge this as I think the bug fix in the abstract grid method may impact other PRs. |
One bug was introduced by PR #7397, while two other were pre-dating that PR. [BFB]
One bug was introduced by PR #7397 , while two other bugs was pre-dating that PR.
@cjvogl If you don't like the nano fix to your ZonalMean diag, another possible solution would be to make the bins span [-90.001,90.001], to ensure that ALL points are inside the bins (and avoid the call to
max
). I think that for even values of ne, unit tests using np4 (gll) grid for physics will always get a column at the north/south poles. Of course, production grids are virtually always using pg2, for which is impossible to get a col exactly at the pole (it would be possible for pg3, but we don't use that).Fixes #7511