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

Making the multi-model statistics preprocessor lazy #781

Closed
Peter9192 opened this issue Sep 15, 2020 · 9 comments · Fixed by #968
Closed

Making the multi-model statistics preprocessor lazy #781

Peter9192 opened this issue Sep 15, 2020 · 9 comments · Fixed by #968
Labels
enhancement New feature or request

Comments

@Peter9192
Copy link
Contributor

The multi-model statistics preprocessor is currently sub-optimal. It operates on Numpy arrays because Iris cubes are quite strict in checking inconsistencies between the input cubes. This workaround impedes lazy evaluation and introduces some vulnerabilites (e.g. #267, #665) and a trail of ad-hoc fixes.

Inconsistent time coordinates were probably the biggest obstacle. However, starting from #677, and continuing in #685, we have already drastically reduced the complexity of time handling. Additionally, #744 proposes to move everything related to 'homogenizing' the time coordinate to the regrid_time preprocessor altogether. Moreover, Iris will soon support lazy regridding (SciTools/iris#3701), so in that case we could really benefit from lazy evaluation in multi-model statistics as well.

In #673, we have implemented a new function that computes 'multi-cube' statistics using Iris build-in functions. This already works for ensemble statistics, because in that case, the cubes are already very homogeneous.

It would be really nice if we could use this Iris 'engine' for the regular multi-model statistics preprocessor as well.

Would you be able to help out?
I might have some time, but it would be good to wait for #685, #744 and #673. In the meantime, this is a placeholder to keep the helicopter view of everything that's happening with the multi-model statistics preprocessor.

@Peter9192 Peter9192 added the enhancement New feature or request label Sep 15, 2020
@stefsmeets
Copy link
Contributor

stefsmeets commented Sep 15, 2020

Also related to #674

@valeriupredoi
Copy link
Contributor

good call! we need to liaise with iris folk - @bjlittle - because a basic multimodel statistic (and lazy altogether) would best sit in iris. We can do it here first but migration to iris is something both us and them would benefit from 🍺

@Peter9192
Copy link
Contributor Author

So what we did in #673 is basically: iris.cube.cubeList(...).merge_cube().collapse() with some fiddling with auxcoords and equalizing attributes. I'm not sure if that warrants a dedicated function in iris or whether it's just a good application of existing functionality. So indeed, I'm curious what @bjlittle has to say about that.

@valeriupredoi
Copy link
Contributor

no, I'm talking about a dedicated iris.analysis.multimodel_statistics(args=(cubes, statistic, ...), **kwargs) function

@Peter9192
Copy link
Contributor Author

Peter9192 commented Sep 16, 2020

I know 🍺. But what I'm saying is that you could also see it as a use case that is already supported by existing functionality in iris. So I'm not sure if really needs to be a dedicated function in iris. But of course I would be happy to see it migrate there eventually.

Btw, I would prefer to name it multi-cube statistics (like I did in #673), because iris is all about cubes, and different cubes are not necessarily different models.

@valeriupredoi
Copy link
Contributor

I need to have a look at #673 👍

@stefsmeets
Copy link
Contributor

We are working on better tests for the multimodel statistics here: #856
Might want to keep an eye on that, as I'm sure this will help with developing the code for this issue.

@Peter9192
Copy link
Contributor Author

#685 is merged!

@schlunma
Copy link
Contributor

schlunma commented Feb 4, 2022

Moving this to v2.6 to follow the corresponding PR.

@schlunma schlunma modified the milestones: v2.5.0, v2.6.0 Feb 4, 2022
@bouweandela bouweandela removed this from the v2.6.0 milestone May 30, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
6 participants