Skip to content

Conversation

@jfrost-mo
Copy link
Member

@jfrost-mo jfrost-mo commented Jan 26, 2026

We now rely on ensemble data having a realization coordinate.
This allows for a significant simplification of the loading process.

Fixes #1808
Fixes #1845

Contribution checklist

Aim to have all relevant checks ticked off before merging. See the developer's guide for more detail.

  • Documentation has been updated to reflect change.
  • New code has tests, and affected old tests have been updated.
  • All tests and CI checks pass.
  • Ensured the pull request title is descriptive.
  • Conda lock files have been updated if dependencies have changed.
  • Attributed any Generative AI, such as GitHub Copilot, used in this PR.
  • Marked the PR as ready to review.

@jfrost-mo jfrost-mo self-assigned this Jan 26, 2026
@jfrost-mo jfrost-mo added the cleanup Non-functional improvement label Jan 26, 2026
@jfrost-mo jfrost-mo marked this pull request as ready for review January 26, 2026 16:19
@github-actions
Copy link
Contributor

github-actions bot commented Jan 26, 2026

Coverage

@jfrost-mo
Copy link
Member Author

jfrost-mo commented Jan 26, 2026

#1872 implements a similar fix to 7cb7d26 as part of a larger set of changes. Note that it will probably conflict.

We now rely on ensemble data having a `realization` coordinate.
This allows for a significant simplification of the loading process.

Fixes #1265
I think this was mostly working coincidentally, as the operations were
also being done in-place. I do, however, expect that the
`iris.util.squeeze(cube)` in _lfric_time_coord_fix_callback was not
applied, which explains some issues we have been having.
This avoids making concatenating cubes difficult before we have done it.
@jfrost-mo jfrost-mo force-pushed the 1265_remove_ensemble_heuristics branch from d020b2e to 7cb7d26 Compare January 26, 2026 16:28
@SGallagherMet
Copy link
Contributor

@mo-tomosevans could you comment on this? I know you've been testing ensemble data
My gut feeling is that this will break out trial and operational data as the 'realisation' number is not included in the cube metadata for the control member so has to be inferred from the file name.
That being said, I'm not sure the code that has been removed would have worked anyway, as the operational and trial file naming conventions are different.

@mo-tomosevans
Copy link

Hi

I think this is PR is something that could address problem I've encountered in #1845. Someone else reported something similar in #1808.

You're right though @SGallagherMet - in the ensemble trial data I've been testing, the ensemble members are given as realization coordinates in the cubes for all but the control member (i.e. <path>/enuk_um_000/enukaa_pd*). In this case there is no realization coordinate by default.

@jfrost-mo
Copy link
Member Author

jfrost-mo commented Jan 27, 2026

the 'realisation' number is not included in the cube metadata for the control member

Am I right in thinking the control would be member 0? If so then it would have a realization coordinate added by the _realization_callback, which should then cause it to merge into a single cube with the other members (assuming I've picked the right coordinate type, etc.)

Is there any operational/trial ensemble data on disk that I could give this a test with?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

cleanup Non-functional improvement

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Not producing member plots for ensemble trials 'Not producing single cube' error reading UM ENS data

4 participants