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

fixing the cutoff-longitude, ckd-lost-in-NaN problem, enabling CS SN computation #235

Merged
merged 18 commits into from
Jul 6, 2022

Conversation

MaceKuailv
Copy link
Collaborator

#215 : Now when you cut off from 179 to -179 you are cutting out 2 degree instead of 358. The test is also updated
#228 : Fillna in the create tree function, so that ckd tree works on llc-rearranged grid.
#234 : A new function in compute.py to calculate the grid orientation using spherical triangles.

@pep8speaks
Copy link

pep8speaks commented Jun 22, 2022

Hello @MaceKuailv! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:

There are currently no PEP 8 issues detected in this Pull Request. Cheers! 🍻

Comment last updated at 2022-07-06 08:25:29 UTC

@ThomasHaine
Copy link
Collaborator

@MaceKuailv please fix the failing tests. Then @malmans2 please review. Thanks!

@codecov
Copy link

codecov bot commented Jun 22, 2022

Codecov Report

Merging #235 (514e150) into master (28b1424) will decrease coverage by 1.15%.
The diff coverage is 37.14%.

@@            Coverage Diff             @@
##           master     #235      +/-   ##
==========================================
- Coverage   96.75%   95.59%   -1.16%     
==========================================
  Files          10       10              
  Lines        3570     3634      +64     
  Branches      775      773       -2     
==========================================
+ Hits         3454     3474      +20     
- Misses         67      109      +42     
- Partials       49       51       +2     
Flag Coverage Δ
unittests 95.59% <37.14%> (-1.16%) ⬇️

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

Impacted Files Coverage Δ
oceanspy/compute.py 97.56% <7.69%> (-1.26%) ⬇️
oceanspy/utils.py 78.57% <30.43%> (-18.15%) ⬇️
oceanspy/_oceandataset.py 97.59% <100.00%> (+<0.01%) ⬆️
oceanspy/subsample.py 98.33% <100.00%> (+0.34%) ⬆️

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 28b1424...514e150. Read the comment docs.

@MaceKuailv
Copy link
Collaborator Author

the conf.py file need to "import oceanspy" which will require import utils which will then "from numba import njit". I have to try except import numba, and if that does not work I need to change njit to a function that reads function f and returns the exact same function f.

Comment on lines 21 to 29
# Jiang being a bit lazy
import numpy as np

try:
from numba import njit
except ImportError: # pragma: no cover

def njit(f):
return f
Copy link
Contributor

@malmans2 malmans2 Jun 23, 2022

Choose a reason for hiding this comment

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

I think it would be a bit cleaner to do something like this:

Suggested change
# Jiang being a bit lazy
import numpy as np
try:
from numba import njit
except ImportError: # pragma: no cover
def njit(f):
return f
import numpy as np
try:
import numba
has_numba = True
except ImportError:
has_numba = False
def conditional_njit(f):
if has_numba:
return numba.njit(f)
return f

I imagine you are seeing quite a bit of improvement using numba. Fell free to use the decorator on other functions as well!

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Thanks a lot for the comment! I assume I need to change all the @njit to @conditional_njit in the rest of the code. Is that correct?

Copy link
Contributor

Choose a reason for hiding this comment

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

correct! also, I haven't tested the snippet above - hopefully it works fine

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

No worries. I am going to test it

Comment on lines 834 to 836
x_stack = x.stack(points=x.dims).fillna(rid_value).values
y_stack = y.stack(points=y.dims).fillna(rid_value).values
z_stack = z.stack(points=z.dims).fillna(rid_value).values
Copy link
Contributor

Choose a reason for hiding this comment

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

Does it work if you use .data instead of .values? That way dask arrays are not loaded into memory.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I haven't tested that. But since the very next step is to feed the whole thing into scipy, I think laziness is not really necessary here. I believe it is also values in the original code

Copy link
Contributor

Choose a reason for hiding this comment

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

Let's use .data if it works. It wasn't available when we first started working on oceanspy and it is possible that SciPy is/will be able to use dask laziness

read the od grid things into numpy arrays
stored in this module
"""
global Z, Zl, dZ, dZl, dXC, dYC, dXG, dYG, XC, XG, YC, YG, CS, SN, tree, ts
Copy link
Contributor

Choose a reason for hiding this comment

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

We should try to avoid global variables as much as possible (or it would be better to use python's cache decorators)

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

That's very true. This is actually a temporary solution. My plan is to put the functions you see here into the _oceandataset as methods, and those global variables in the util module will be in the class oceandataset. But oceandataset is very fundamental to a lot of the operations, so I want to be more careful when making changes to it.

@Mikejmnez
Copy link
Collaborator

@MaceKuailv the variables CS and SN are not available on the dataset after reading it with oceanspy (see issue #234 ) because in the intake catalog, I decided to drop them - I didn't think they were relevant to users but I see I was mistaken. You can include these variables by simply commenting the line 726 in /sciserver_catalogs/catalog_xarray.yaml the line 726. You can still keep the function you created for calculating these variables (and perhaps write a test to compare) as I think it still might be useful.

@@ -2833,6 +2834,43 @@ def salt_budget(od):
return _ospy.OceanDataset(ds).dataset


def find_cs_sn(thetaA, phiA, thetaB, phiB):
"""
theta is the angle
Copy link
Collaborator

@Mikejmnez Mikejmnez Jun 29, 2022

Choose a reason for hiding this comment

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

You should improve the description of this function. What does it do? Input and outputs.

@@ -18,6 +18,31 @@
except ImportError: # pragma: no cover
pass

import numpy as np
Copy link
Collaborator

Choose a reason for hiding this comment

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

do instead

import numpy as _np

this is consistent with the rest of oceanspy.

CS = np.array(od._ds.CS).astype("float32")
SN = np.array(od._ds.SN).astype("float32")
tree = od.create_tree(gridtype)
if gridtype == "C":
Copy link
Collaborator

@Mikejmnez Mikejmnez Jun 29, 2022

Choose a reason for hiding this comment

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

This can create confusion, since oceanspy is only compatible with c-grids. Instead of gridtype, use something like gridloc (as in location) or something. We don't want to suggest that these are different types of grids...

Copy link
Collaborator

Choose a reason for hiding this comment

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

@MaceKuailv Please make these fixes and @asiddi24 will investigate the failing 3.10 build (also for #237).

@ThomasHaine ThomasHaine mentioned this pull request Jul 5, 2022
@MaceKuailv
Copy link
Collaborator Author

Ready to be merged when the _xe problem is fixed

@malmans2
Copy link
Contributor

malmans2 commented Jul 6, 2022

Ready to be merged when the _xe problem is fixed

See #238

@malmans2
Copy link
Contributor

malmans2 commented Jul 6, 2022

If you trigger the CI should be all good now

Copy link
Collaborator

@ThomasHaine ThomasHaine 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.

@ThomasHaine ThomasHaine merged commit b8eb69a into hainegroup:master Jul 6, 2022
@MaceKuailv
Copy link
Collaborator Author

Noice

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.

5 participants