Skip to content
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

Fix check for tripolar Laplacian #123

Merged
merged 5 commits into from Jan 26, 2022

Conversation

NoraLoose
Copy link
Member

Closes #122.

Problem description

The tripolar Laplacian POPTripolarLaplacianTpoint checks that the northern edge grid data folds onto itself - a necessary criterion of the tripole grid geometry. However, this check failed when this Laplacian got applied to some actual POP grid data (rather than just our synthetic test data in our package), such as in our example notebook in the documentation.

Solution

I changed the check to only test along northern edge grid data that is not on land. The POP grid data goes a little bit crazy on land points--and does whatever--, so we don't want to check on land. The check now passes.

Lesson learned

This brings us back to an old question in #5: Should we do our tests on real model data, or at least, real model grid data (rather than synthetic data)? We would have discovered this issue much earlier...

- test that northern edge grid data folds onto itself *only* away
  from land
@codecov-commenter
Copy link

codecov-commenter commented Dec 18, 2021

Codecov Report

Merging #123 (25bb409) into master (7898c9c) will not change coverage.
The diff coverage is 100.00%.

Impacted file tree graph

@@           Coverage Diff           @@
##           master     #123   +/-   ##
=======================================
  Coverage   98.41%   98.41%           
=======================================
  Files           9        9           
  Lines         944      944           
=======================================
  Hits          929      929           
  Misses         15       15           
Flag Coverage Δ
unittests 98.41% <100.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
tests/test_kernels.py 100.00% <ø> (ø)
gcm_filters/kernels.py 98.56% <100.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7898c9c...25bb409. Read the comment docs.

@rabernat
Copy link
Contributor

Hi Nora! Thanks for working on this important issue. Unfortunately I am about to unplug for my holiday break. I will be back online the first week of January and will try to review this then. If you want to move faster, then you don't have to wait for me. On the other hand, I hope you (and everyone else involved) is also planning to take a break as well! 🎄🎅🎄

@NoraLoose
Copy link
Member Author

Yes, let's finish this PR and the remaining issues related to the JOSS review in the first week of January. Happy holidays!

@NoraLoose
Copy link
Member Author

Would anyone be willing to review this PR?

# note: grid data goes crazy for POP model land points so we don't want to check for land points
nx = np.shape(self.dxn)[-1] # number of longitudes or columns
# grab second to last row since we have already appended one extra row
first_half = (self.n_wet_mask * self.dxn)[..., [-2], : (nx // 2)]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might be better to do this test with boolean indexing rather than multiplying by the wet mask. If, for example, some of the land data is NaN then I think this test would throw an error because 0 * np.NaN is np.NaN and np.NaN == np.NaN returns False. Maybe something like
first_half = self.dxn[...,-2,self.n_wet_mask[...,-2,:(nx//2)] == 1]
would avoid NaN problems.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the catch! In my latest commit I followed your suggestion - just using a different syntax that will also work with dask and cupy.

@NoraLoose
Copy link
Member Author

@iangrooms do you now approve this PR? If so I would like to merge this, so we can move forward with our JOSS revisions.

Copy link
Member

@iangrooms iangrooms left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me. Thanks for your work on this!

@NoraLoose NoraLoose merged commit a2d9766 into ocean-eddy-cpt:master Jan 26, 2022
@NoraLoose NoraLoose deleted the fix-tripole-laplacian branch January 26, 2022 23:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Tripole boundary check does not pass on POP data
4 participants