-
Notifications
You must be signed in to change notification settings - Fork 81
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
adding boundary condition #325
Conversation
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 really fantastic @rcaneill! Thanks so much for your work.
Just one suggestion and one question. Otherwise LGTM!
g | ||
|
||
We show here the value of the extra added point for 5 cases (extended, extrapolated, filled with 0, filled with 5, | ||
and periodic). The periodic condition is not an argument of the methods, but is provided |
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.
An API question: do you think we should change things so that all boundary conditions (including periodic) are handled in the same way?
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.
Good question. I also asked myself about this while writing. Maybe just being able to overwrite the boundary condition at any time while calling the grid methods would be nice. So keep the periodic argument in the grid init, along with the boundary argument, but overwrite them when explicitly asked by user.
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.
Fully in favour. See #195
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 should actually do that, but have to go through a deprecation cycle.
This is really cool @rcaneill! Thank you very much for working on this.
I had some other small nits for the code, but overall this looks amazing! |
doc/grids.rst
Outdated
.. ipython:: python | ||
|
||
def plot_bc(ds): | ||
plt.plot(ds.x_g, g, marker='o', color='C6', label='g') |
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 code block (and the following), do not show up nicely in the Readthedocs preview (https://xgcm--325.org.readthedocs.build/en/325/grids.html) because the lines are too long.
Could you shorten the lines? Ideally you would use black to format each code cell and then paste it back? I also wonder if there is a way to do this automatically. Ill open an issue for that in the future.
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.
The remaining issues with formatting are problems with our sphinx theme, not this PR. |
So, should I just commit the 2 lines that are changed by black and that's it? |
Or just do nothing and we can deal with it in #326. 😄 |
Ahh 💩 seems like my black advice had some unintended consequences, and you reformatted some of the source code here. Could you follow these steps, which should fix the source code again, but should not touch the docs. Sorry for making this more complicated than necessary. |
I tried to fix the formatting here (since its good to go otherwise), but I am getting:
it seems this part is upsetting blackdoc:
@rcaneill do we necessarily need this? @andersy005 do you have an idea how to fix this? |
Plotting the grid is not essential, it is just that I found it more clear and easier to refer to the value of each condition (as I choose the number to be integer and be located in the grid lines) |
Co-authored-by: keewis <keewis@users.noreply.github.com>
there is also a bug in |
I don't know why it does not pass the code-style / pre-commit check now... The error is:
|
yes, that's the bug I was talking about in #325 (comment). The fix is to upgrade the version of |
I changed the code blocks so it passes all the tests and I am happy with the way it looks. I think it's ready for merging :) |
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.
Thank you for this excellent addition and the tremendous patience @rcaneill.
g | ||
|
||
We show here the value of the extra added point for 5 cases (extended, extrapolated, filled with 0, filled with 5, | ||
and periodic). The periodic condition is not an argument of the methods, but is provided |
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 should actually do that, but have to go through a deprecation cycle.
Oh I forgot one thing! You should give yourself credit in |
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.
So sorry for the long wait again @rcaneill. Really appreciate your tenacity here. Good news is this will now be included in v0.6.0 (which we are releasing today).
Thanks again for this important contribution
Aims to close #273
I added a section about the boundary conditions. I also corrected some minor typos.