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

Loading in multiple forecasts in netcdf format creates multiple cubes rather than a single cube #1114

Open
daflack opened this issue Feb 3, 2025 · 3 comments
Labels
bug Something isn't working

Comments

@daflack
Copy link
Contributor

daflack commented Feb 3, 2025

Describe the bug

Cubes in netcdfs when read in will create a cube list rather than a cube with forecast_reference_time and forecast_period. This led to needing ensure_aggregatable_across_cases but this operator will not work with the difference plots. Therefore, we need to use the "slice and dice method" in read_cubes to produce relevant single cubes.

How to reproduce

Steps to reproduce the behaviour:

  1. Load multiple forecasts at the same time in netcdf format
  2. See they are loaded in CubeList

Expected behaviour

Cubes from multiple forecasts should come as a single cube.

Environment

  • Version: [e.g. from cset --version]
  • Browser (if UI issue): [e.g. Chrome, Firefox]
@daflack daflack added the bug Something isn't working label Feb 3, 2025
@daflack daflack changed the title Spatial difference case aggregation does not work Loading in multiple forecasts in netcdf format creates multiple cubes rather than a single cube Feb 3, 2025
@daflack
Copy link
Contributor Author

daflack commented Feb 3, 2025

Due to the usage of read_cubes "slice and dice" is not the solution for this problem.

@jfrost-mo
Copy link
Member

I've just been in the AVD surgery to determine the cause of the non-merging coordinates in NetCDF files. It comes from where the NetCDF file has the time coordinate as an extra dimension in the underlying cube, where PP files have each field being a scalar one, so essentially it is already broken apart.

I've got a suggestion of where to fix it in CSET, and considerations around how to make it reasonably efficient, though it will have some performance cost still.

@jfrost-mo
Copy link
Member

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants