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

adding boundary condition #325

Merged
merged 17 commits into from
Dec 3, 2021
Merged

Conversation

rcaneill
Copy link
Contributor

Aims to close #273

I added a section about the boundary conditions. I also corrected some minor typos.

Copy link
Contributor

@rabernat rabernat left a 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!

doc/grids.rst Outdated Show resolved Hide resolved
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
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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

Copy link
Contributor

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.

@jbusecke
Copy link
Contributor

This is really cool @rcaneill! Thank you very much for working on this.
There are a few issues that might be relevant here:

  • Since we demonstrate the extrapolate option, we should really clean up where and when we can apply that. This has been a 'semi-hidden' feature for a long time I think (fix boundary="extrapolate" #206)
  • boundary="periodic"? #195 seems relevant for the discussion started by @rabernat above. My two cents: I think this makes sense without loosing generality?

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')
Copy link
Contributor

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.

See this example:
image

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I just tried to use black (and copy/paste), but it does not seem to solve the problem
xgcm-doc-black

@rabernat
Copy link
Contributor

The remaining issues with formatting are problems with our sphinx theme, not this PR.

@rcaneill
Copy link
Contributor Author

So, should I just commit the 2 lines that are changed by black and that's it?

@rabernat
Copy link
Contributor

Or just do nothing and we can deal with it in #326. 😄

@jbusecke
Copy link
Contributor

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.

@jbusecke jbusecke self-assigned this Jul 6, 2021
@jdldeauna jdldeauna mentioned this pull request Jul 28, 2021
1 task
@jbusecke
Copy link
Contributor

I tried to fix the formatting here (since its good to go otherwise), but I am getting:

error: cannot format /Users/juliusbusecke/code/xgcm/doc/grids.rst: Cannot parse: 403:0: plt.grid(True)

it seems this part is upsetting blackdoc:

    @suppress
    plt.grid(True)
    @savefig grid_bc_extra_point.png
    plot_bc(ds)

@rcaneill do we necessarily need this? @andersy005 do you have an idea how to fix this?

@rcaneill
Copy link
Contributor Author

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)

doc/grids.rst Outdated Show resolved Hide resolved
rcaneill and others added 3 commits September 3, 2021 17:19
@keewis
Copy link
Contributor

keewis commented Sep 3, 2021

there is also a bug in blackdoc which is fixed in v0.3.4, so you'd need to update the version in .pre-commit-config.yaml to get it to pass

@rcaneill
Copy link
Contributor Author

rcaneill commented Sep 3, 2021

I don't know why it does not pass the code-style / pre-commit check now... The error is:

Traceback (most recent call last): File "/home/romain/.cache/pre-commit/repobuk3dc8i/py_env-python3/bin/blackdoc", line 5, in <module> from blackdoc.__main__ import main File "/home/romain/.cache/pre-commit/repobuk3dc8i/py_env-python3/lib/python3.9/site-packages/blackdoc/__main__.py", line 12, in <module> from .blackcompat import ( File "/home/romain/.cache/pre-commit/repobuk3dc8i/py_env-python3/lib/python3.9/site-packages/blackdoc/blackcompat.py", line 9, in <module> import toml ModuleNotFoundError: No module named 'toml'

@keewis
Copy link
Contributor

keewis commented Sep 3, 2021

yes, that's the bug I was talking about in #325 (comment). The fix is to upgrade the version of blackdoc.

@rcaneill
Copy link
Contributor Author

rcaneill commented Sep 4, 2021

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 :)

Copy link
Contributor

@jbusecke jbusecke left a 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
Copy link
Contributor

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.

@jbusecke
Copy link
Contributor

Oh I forgot one thing! You should give yourself credit in docs/whats-new.rst @rcaneill. Then ill merge this immediately.

Copy link
Contributor

@jbusecke jbusecke left a 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

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.

We need a section in the docs about 'boundary' and 'fill'[DOC]
5 participants