Skip to content

Generate time lagged ensemble with deterministic input#2316

Open
gavinevans wants to merge 4 commits intometoppv:masterfrom
gavinevans:mobt_1078_time_lagged_deterministic
Open

Generate time lagged ensemble with deterministic input#2316
gavinevans wants to merge 4 commits intometoppv:masterfrom
gavinevans:mobt_1078_time_lagged_deterministic

Conversation

@gavinevans
Copy link
Contributor

Addresses https://github.com/metoppv/mo-blue-team/issues/1078

Description
This PR makes a minor update the GenerateTimeLaggedEnsemble plugin to support providing deterministic input (i.e. input without a realization coordinate), so that a time-lagged ensemble can be created using deterministic inputs.

Testing:

  • Ran tests and they passed OK
  • Added new tests for the new feature(s)

@maxwhitemet maxwhitemet self-requested a review March 2, 2026 09:59
Copy link
Contributor

@maxwhitemet maxwhitemet left a comment

Choose a reason for hiding this comment

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

Thanks @gavinevans. I have added some comments

@@ -19,6 +20,32 @@
class GenerateTimeLaggedEnsemble(BasePlugin):
"""Combine realizations from different forecast cycles into one cube"""
Copy link
Contributor

Choose a reason for hiding this comment

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

To be explicit, please could you add some comments on how the realization coordinate points are handled both when no realization coordinate is present on any cubes and when some cubes have realization coordinates and others don't. Some supporting examples would help.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I've extended this docstring.

Comment on lines 77 to 81
Copy link
Contributor

Choose a reason for hiding this comment

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

Following the 'Fail fast' principle, this should be moved above the use of the add_realization_coord method.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I've left this, as I think that I'd prefer the case where a single cube is input, with this cube then being returned, but with a realization coordinate added, to have precedence over the case where the times are compared between multiple cubes, which could result in a failure.

Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
# Take all the realizations from all the input cubes and

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I've refactored code on surrounding lines.

input_cubelist = iris.cube.CubeList([cube1, cube2])
result = GenerateTimeLaggedEnsemble().process(input_cubelist)
self.assertIn("realization", [coord.name() for coord in result.coords()])
np.testing.assert_array_equal(result.coord("realization").points, [0, 3, 4, 5])
Copy link
Contributor

Choose a reason for hiding this comment

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

Although this passes, is this desireable? Would we instead want to ensure that the points are monotonically increasing with constant stride (i.e., [0, 1, 2, 3, 4, 5] rather than [0, 3, 4, 5])? I'm wondering what downstream code expects

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The case of mixed realizations is probably least likely to be actively used, but I've added an option to rebadge the realizations, rather than do this automatically, in case the numbers used within the input realizations do have meaning.

@gavinevans gavinevans force-pushed the mobt_1078_time_lagged_deterministic branch from 012b591 to d579516 Compare March 2, 2026 13:42
Copy link
Contributor

@maxwhitemet maxwhitemet left a comment

Choose a reason for hiding this comment

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

Thanks @gavinevans. Happy with the changes made. Approved 👍

Copy link
Contributor

@Kat-90 Kat-90 left a comment

Choose a reason for hiding this comment

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

Only a couple of minor comments.


def test_single_cube(self):
"""Test only one input cube returns cube unchanged"""
"""Test only one input cube returns the cube unchanged and raises a warning."""
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe this should be changed to something more specific now because you can now change a single input cube by passing in a deterministic one. The warning would also change slightly.
Something like "Only single cube input with realization coord already present, so time lagging will have no effect."?

It might be worth adding a warning to the deterministic cube too that says "Only single deterministic cube input, so realization coord added but time lagging will have no effect."


def test_single_cube_without_realization(self):
"""Test single input cube without realization coordinate gets one added."""
# Remove realization coordinate
Copy link
Contributor

Choose a reason for hiding this comment

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

If my above comment makes sense then we would add a warning to this unit test too.

np.testing.assert_array_equal(result.coord("realization").points, [0, 1])

def test_mixed_cubes_with_and_without_realization(self):
"""Test mixing cubes with and without realization coordinates."""
Copy link
Contributor

Choose a reason for hiding this comment

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

Could we add what we expect to happen in the docstring like the others. I think it's that the cube without a realization coord gets one sequentially starting from 0.

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.

3 participants