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

Allow passing None for all coord-system optional args. #3804

Merged
merged 13 commits into from
Sep 15, 2020

Conversation

pp-mo
Copy link
Member

@pp-mo pp-mo commented Aug 25, 2020

The need for this is due to the way the netcdf load rules translate the attributes of a grid-mapping variable into a coordinate system : The functions "build_xxx_coordinate_system" (in the Pyke rules, e.g. here) fetch netcdf var attributes defaulted to None, and then call the class constructor expecting it to fill in defaults for unspecified arguments. But this cannot work if the constructor relies on an optional argument definition of the form "arg=number", e.g. here :
So instead, the CoordSystem constructors should be capable of accepting an "arg=None" and applying a default.

Aiming at:
closes #3629
closes #3675

@bjlittle bjlittle added this to the v3.0.0 milestone Sep 7, 2020
@pp-mo pp-mo self-assigned this Sep 8, 2020
@trexfeathers trexfeathers self-requested a review September 9, 2020 10:18
Copy link
Contributor

@trexfeathers trexfeathers left a comment

Choose a reason for hiding this comment

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

Thanks @pp-mo, this is a whopper! Definitely takes the record for the largest PR I have reviewed. I'm particularly impressed that - despite what I assume was a lot of copy-paste - each of the tests refers to the correct variables and the correct defaults. And despite the large number of changed coordinate systems almost everything had the right corresponding tests, although see the note below. Top work! 🏆 💐


Further to my specific code comments, here are some notes on possible missing coverage for the pyke rules tests:

* false_easting
X offset from planar origin in metres.
Defaults to 0.
Copy link
Contributor

Choose a reason for hiding this comment

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

Is there a reason you're not saying Defaults to 0.0. for consistency?

Copy link
Member Author

Choose a reason for hiding this comment

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

No!

Copy link
Contributor

Choose a reason for hiding this comment

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

Still at:

lib/iris/coord_systems.py Outdated Show resolved Hide resolved
lib/iris/coord_systems.py Outdated Show resolved Hide resolved
docs/iris/src/whatsnew/latest.rst Outdated Show resolved Hide resolved
docs/iris/src/whatsnew/latest.rst Show resolved Hide resolved
@pp-mo
Copy link
Member Author

pp-mo commented Sep 11, 2020

why there is no fc_rules_cf_fc.build_orthographic_coordinate_system?

It looks like we just don't support this for netcdf load.
A lot of the confusion here is generated by the differences between what netcdf currently supports and the generic iris coord-systems code.
Which only exacerbates a lot of tiresome nearly-but-not-quite-the-same-ness in the CF rules.

@pp-mo
Copy link
Member Author

pp-mo commented Sep 11, 2020

Missing equivalent test coverage for:

  • fc_rules_cf_fc.build_coordinate_system
  • fc_rules_cf_fc.build_rotated_coordinate_system

These are not affected by the primary code changes, because they do not support false_easting/northing parameters : they only exist in non-latlon systems.
So I think it's certainly true there is testing missing here, but it's historical and we are not obliged to address it now.

Frankly, there is a lot that is untidy and missing in the existing testing strategies, for both the iris coord-systems, and the netcdf loading. All the tests in iris.tests which are neither under iris.tests.unit nor iris.tests.integration, are effectively outdated, for a start.
I have explicitly opted for a "minimum changes" approach here, providing only the needed new tests, which I think should be less confusing, and hopefully less work, for both of us : Whilst it might actually have been simpler to rationalise the existing stuff first, I thought it looked like a lot of work, and addressing the missing parts was particularly likely to cause overcomplication.

P.S. I just noticed this, prior art which relates : #3409

Copy link
Member Author

@pp-mo pp-mo left a comment

Choose a reason for hiding this comment

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

Initial comments -- not done yet ...

docs/iris/src/whatsnew/latest.rst Outdated Show resolved Hide resolved
lib/iris/coord_systems.py Outdated Show resolved Hide resolved
lib/iris/coord_systems.py Outdated Show resolved Hide resolved
Copy link
Contributor

@trexfeathers trexfeathers left a comment

Choose a reason for hiding this comment

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

Thanks for the hard work @pp-mo , I consider my comments largely addressed, with the exception of the two new comments below.


* false_easting
X offset from planar origin in metres.
X offset from planar origin in metres. Defaults to 0
Copy link
Contributor

Choose a reason for hiding this comment

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

@pp-mo and I have agreed offline that this file needs a quick check through to make sure docstrings consistently make it clear that the defaults are float types, since different lines containing integers and floats may be misinterpreted as actual different behaviour.

pp-mo and others added 2 commits September 14, 2020 15:38
Co-authored-by: Martin Yeo <40734014+trexfeathers@users.noreply.github.com>
@pp-mo
Copy link
Member Author

pp-mo commented Sep 14, 2020

I decided in the end to rationalise all the docstrings,
so I hope this suits.
I have tried to put them all into the existing iris-format, as even though we may be close to adopting something different #3840, I think we aren't totally decided on numpy style yet.

I also considered adding types for all the instance parameters, e.g. #: X offset from planar origin in metres (float)., but it seemed fussy + unnecessary (and we don't have a definite style for it anyway).

@trexfeathers
Copy link
Contributor

Great work @pp-mo 👌 LGTM

@trexfeathers trexfeathers merged commit 3e9a094 into SciTools:master Sep 15, 2020
trexfeathers added a commit to trexfeathers/iris that referenced this pull request Sep 15, 2020
tkknight added a commit to tkknight/iris that referenced this pull request Sep 15, 2020
* master:
  whatsnew - using the author github id (SciTools#3849)
  Bring SciTools#3804 whatsnew in line with format changes from SciTools#3838. (SciTools#3847)
  "What's New" credit and referencing (SciTools#3838)
  Allow passing None for all coord-system optional args. (SciTools#3804)
  var_name in AuxCoord created by trajectory.interpolate() (SciTools#3718)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants