Describe the bug
When running scores for a variable wind_speed_at_10m, for two models and observations, I found that the following was being passed to the function:
2026-08-11 16:02:10,269 CSET.operators DEBUG step_input: 0: eastward_wind_at_10m / (m s-1) (time: 48; grid_latitude: 342; grid_longitude: 347)
1: northward_wind_at_10m / (m s-1) (time: 48; grid_latitude: 342; grid_longitude: 347)
2: observed_wind_speed_at_10m / (ms-1) (time: 48; station: 198)
3: wind_speed / (ms-1) (time: 48; grid_latitude: 342; grid_longitude: 348)
4: wind_speed_at_10m / (m s-1) (time: 48; grid_latitude: 342; grid_longitude: 347)
Which caused problems, as northward_wind_at_10m and eastward_wind_at_10m shouldn't be there. Now, I could do repeat filtering at this stage, but we don't really want these extra variables propagating through the code from the read.py step, as this might disrupt intermediate operators.
The problem stems from constraints.generate_var_constraint, which relaxes the varname requirement when wind_speed_at_10m is requested, as we need eastward and northward components of wind to derive this. If we constrain only on wind speed, we don't have access to these components and thus cant derive it.
After the constraining, _compute_winds is called in read._load_model. This works OK in UM, but not in LFRic. In LFRic:
If wind_speed_at_10m is requested, this function will recieve wind_speed_at_10m, northward_wind_at_10m , eastward_wind_at_10m , as these all exist natively in LFRic. If a user requests eastward_wind_at_10m and wind_speed_at_10m, the same will be returned.
Given that the constraint given by the user is modified, it is difficult to find out what combination of variables the user actually wants to constrain on.
I.e. the original user constraint is being mutated into a data-loading constraint, and then the information about what the user actually requested is lost.
How to reproduce
Steps to reproduce the behaviour:
Expected behaviour
We should
user request
↓
expand dependencies
↓
iris.load()
↓
_compute_winds()
↓
filter back to requested_vars
Describe the bug
When running scores for a variable
wind_speed_at_10m, for two models and observations, I found that the following was being passed to the function:Which caused problems, as
northward_wind_at_10mandeastward_wind_at_10mshouldn't be there. Now, I could do repeat filtering at this stage, but we don't really want these extra variables propagating through the code from theread.pystep, as this might disrupt intermediate operators.The problem stems from
constraints.generate_var_constraint, which relaxes thevarnamerequirement whenwind_speed_at_10mis requested, as we need eastward and northward components of wind to derive this. If we constrain only on wind speed, we don't have access to these components and thus cant derive it.After the constraining,
_compute_windsis called inread._load_model. This works OK in UM, but not in LFRic. In LFRic:If
wind_speed_at_10mis requested, this function will recievewind_speed_at_10m, northward_wind_at_10m , eastward_wind_at_10m, as these all exist natively in LFRic. If a user requestseastward_wind_at_10m and wind_speed_at_10m, the same will be returned.Given that the constraint given by the user is modified, it is difficult to find out what combination of variables the user actually wants to constrain on.
I.e. the original user constraint is being mutated into a data-loading constraint, and then the information about what the user actually requested is lost.
How to reproduce
Steps to reproduce the behaviour:
Expected behaviour
We should
user request
↓
expand dependencies
↓
iris.load()
↓
_compute_winds()
↓
filter back to requested_vars