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
add zgr and zco classes #15
Conversation
Codecov Report
@@ Coverage Diff @@
## main #15 +/- ##
==========================================
+ Coverage 92.30% 93.12% +0.81%
==========================================
Files 2 4 +2
Lines 39 160 +121
==========================================
+ Hits 36 149 +113
- Misses 3 11 +8
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
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.
I added comments that should make darglint happy.
Next step I am going to write the test. Thanks @malmans2 for the help with the bloody darglint ;) :) |
Any idea why the failing of CI / upstream-dev (pull_request)? |
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.
I've only glanced through it, but here are a few xarray
tips.
Must have been a connection hiccup. I re-triggered it and looks OK. |
Co-authored-by: Mattia Almansi <mattia.almansi@noc.ac.uk>
Co-authored-by: Mattia Almansi <mattia.almansi@noc.ac.uk>
Co-authored-by: Mattia Almansi <mattia.almansi@noc.ac.uk>
Ok so let me just write down my next steps:
Any other things we want to add? |
Looks good. As you are not going to add that much at this point, I think 3 can wait after 4 so we can safely refactor if we need to. Just one comment about testing, I think the best way is to only test public methods (aka, easier to maintain and if we don't hit all private methods testing public methods, something is not right... codecov will tell us). |
Co-authored-by: Mattia Almansi <mattia.almansi@noc.ac.uk>
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.
There a few times where I think for loops of the kind for var in (varT, varK)
clarify when the same thing is done and will prevent typos and bugs...
I've used GH inline comments without running the code so please double check if you are going to implement it.
Also, does it make sense to isolate the entire for loop in __call__
that generates ds["z3{T,W}"]
in a separate method? That way __call__
is very clean and just glancing through it shows all the steps that are done.
I also just realized that all the inline for varname, kx, sig, sig_p1 in zip(["z3T", "z3W"], [kindx, kindx + 1.], sigmas, sigmas_p1): so pretty much the same as this: #15 (comment) |
When we have the tests, I think this will be the way to go: |
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.
Final minor comments...
pydomcfg/tests/test_zco.py
Outdated
jpk = 31 | ||
|
||
# Bathymetry dataset | ||
ds_bathy = Bathymetry(1000.0, 1200.0, 100, 200).flat(5000.0) |
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.
What if we test:
ds_bathy = Bathymetry(1000.0, 1200.0, 1, 1).flat(5000.0)
and possibly we have a separate test to make sure that all z/e3 are identical for 2D flat domains?
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.
Sorry but I don't understand what you mean ...
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 is the code that fail mypy |
if not self._is_uniform: | ||
self._ppsur, self._ppa0, self._ppa1 = self._compute_pp(ppsur, ppa0, ppa1) |
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.
I think we are missing an error here, i.e. the case where is uniform and the user provides any of [ppsur, ppa0, ppa1]
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.
If the user wants a uniform grid (acr or kth == 0) then we don't need ppsur, ppa0 and ppa1 at all - they are not used. So even if the user provide ppsur, ppa0 and ppa1, the condition of uniform grid prevent to set them. I think we are safe like this.
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.
OK! Still the user is probably misunderstanding something... Let's add a warning?
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.
OK! Still the user is probably misunderstanding something... Let's add a warning?
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.
Fine by me
Co-authored-by: Mattia Almansi <mattia.almansi@noc.ac.uk>
No description provided.