xgcm
xgcm copied to clipboard
xgcm
Implementing axis directionality
This is a first pass at implementing direction-aware axes (#337), including a preliminary test, with thanks to @jbusecke. The main behavior is to define a sign for the Grid.diff function.
There was some discussion in #337 about naming conventions. I have implemented just a simple version here wherein a direction (increasing or decreasing) is specified at the point of defining the grid. Happy to iterate on this logic.
I was not sure what would be the correct way to define the default behavior. Here I have specified that None defaults to assuming that all axes are increasing. This leads to some redundancy, but keeps the default conventions consistent with the API for other variables.
- [x] Closes #337
- [x] Tests added
- [ ] Passes
pre-commit run --all-files - [ ] User visible changes (including notable bug fixes) are documented in
whats-new.rst - [ ] New functions/methods are listed in
api.rst
You should be able to get the pre-commit CI to pass by following these steps. You can also install the black formatter for vscode 😜
Thanks for these thoughts and suggestions @jbusecke, I will get to them next week.
I would like to pick up this discussion here, now that #344 is implemented. I believe we still need to agree on the naming, but I was also curious if there is a way to implement the sign swapping inside the grid_ufuncs (avoiding additional dask tasks)?
cc @TomNicholas
if there is a way to implement the sign swapping inside the grid_ufuncs (avoiding additional dask tasks)
multiplying works blockwise, so it'll just get fused no?
multiplying works blockwise, so it'll just get fused no?
Ah yes good point!
I think this predates the grid_ufunc internals and as such would probably be a heck of a lot of work to refactor. I would recommend to revisit the discussion in #337 and then discuss a new implementation (a generalization of what you did in #609 seems like a good start)