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

fix: handle indexing changes in new xarray versions #159

Merged
merged 2 commits into from Mar 30, 2024

Conversation

slevang
Copy link
Collaborator

@slevang slevang commented Mar 29, 2024

Finally figured out a solution to the indexing woes with serialization of multiindexes on newer xarray versions.

In updating to >2023.12.0, we were also getting a failure when doing xr.dot across dim="mode" in the inverse transforms when selecting out a singleton mode.

@nicrie not sure if you have a preference for how to update poetry.lock, I aimed for minimal changes here by just relaxing the xarray version constraint and bumping to latest in the lock file.

@slevang slevang requested a review from nicrie March 29, 2024 18:35
Copy link

codecov bot commented Mar 29, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

❗ No coverage uploaded for pull request base (main@a3cb204). Click here to learn what that means.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #159   +/-   ##
=======================================
  Coverage        ?   94.44%           
=======================================
  Files           ?       73           
  Lines           ?     6225           
  Branches        ?        0           
=======================================
  Hits            ?     5879           
  Misses          ?      346           
  Partials        ?        0           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link
Collaborator

@nicrie nicrie left a comment

Choose a reason for hiding this comment

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

Awesome @slevang, thanks for digging into this! :) Just a minor thing regarding the "mode".

As for the poetry.lock I have no preference tbh. I started using Poetry 2 years ago as it seemed to be the future to me, but not sure anymore about it ;) I've already thought about dropping it all together and using conda together with a requirements file. In case you have a strong preference for any of these two options or even another way, I'm super open :)

Comment on lines 148 to 151
# Handle scalar mode
if "mode" not in scores.dims:
scores = scores.expand_dims("mode")

Copy link
Collaborator

Choose a reason for hiding this comment

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

Perhaps it's better to add the "mode" dimensions in the _BaseModel class, since we also remove the "mode" dim there afterward? Plus other models can inherit this behaviour :)

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Of course, good idea, I had only followed the traceback to where I hit the error and added a quick fix.

Comment on lines 282 to 287
# Handle scalar mode
if "mode" not in scores1.dims:
scores1 = scores1.expand_dims("mode")
if "mode" not in scores2.dims:
scores2 = scores2.expand_dims("mode")

Copy link
Collaborator

Choose a reason for hiding this comment

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

same here like in the eof.py module - probably better to move it to inverse_transform within the _base_cross_model.py.

@slevang
Copy link
Collaborator Author

slevang commented Mar 30, 2024

Yeah no strong opinion about poetry, I think it works fine. Personally I use conda environments with pip to install packages for the most part.

One thing I would say is that running CI on unconstrained latest versions of dependencies is quite beneficial to get ahead of compatibility issues. Basing CI off the fixed lock file makes that challenging, so one option would be to just remove the lock file from git. Without that I believe poetry will solve for latest compatible dependencies.

@nicrie
Copy link
Collaborator

nicrie commented Mar 30, 2024

One thing I would say is that running CI on unconstrained latest versions of dependencies is quite beneficial to get ahead of compatibility issues. Basing CI off the fixed lock file makes that challenging, so one option would be to just remove the lock file from git. Without that I believe poetry will solve for latest compatible dependencies.

Yeah good point that seems indeed smarter.
The PR looks good to me, thanks again for solving that :) I'll hit the button

@nicrie nicrie merged commit 7d07d30 into main Mar 30, 2024
7 checks passed
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.

None yet

2 participants