Coordinate valid range and intersection issue
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 45/100
Research direction
Start by reproducing the issue with cube.intersection, iris.save, and loading the resulting NetCDF file using the longitude range described. Trace how the longitude valid_range and points are handled during intersection and reload; done means the saved cube reloads without the warning and preserves the expected -3 through 3 longitude coordinates.
Written by the indexing model from the issue text.
Description
🐛 Bug Report
I have an issue reloading a cube I've saved:
I start with a cube with longitude coordinate 0-360, and do
new_cube = cube.intersection(longitude=(-3,3))
and I get a new cube with the correct longitudes -3 -2 -1 0 1 2 3
When I save this,
iris.save(new_cube, "file.nc")
and then load back in, the longitude coordinate generates this error/warning:
UserWarning: Failed to create 'longitude' dimension coordinate: The 'longitude' DimCoord points array must be strictly monotonic.Gracefully creating 'longitude' auxiliary coordinate instead.
And has points 9.96920997e+36, 9.96920997e+36, 9.96920997e+36, 0, 1, 2, 3
How To Reproduce
Steps to reproduce the behaviour:
- Start with a cube with longitude coordinates in the range 0-360
- Make a new cube using cube.intersection to get a cube with longitude crossing the prime meridian, eg from -3 to +3
- Save the new cube as netcdf
- Load the netcdf file in
- The loaded cube produces the above UserWarning and incorrect longitude values for the negative region
Expected behaviour
The cube when loaded back in I expect to have longitude coordinates in the range -180 to +180
Screenshots
Environment
- OS & Version: Met Office RHEL 7, scitools current default as of 8/6/23
- Iris Version: 3.3.1
Additional context
Click to expand this section...
Please add additional verbose information in this section e.g., code, output, tracebacks, screenshots etc
Doing his before saving
`new_cube.coord('longitude').attributes['valid_range']=np.array([-180,180])`
seems to prevent the issue but I'd expect the new_cube to automatically change its valid_range when making the intersection.
- Dominant language
- Python
- Stars
- 724
- Forks
- 317
- Avg merge
- 3d 20h
- Merged PRs (30d)
- 9
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from SciTools/iris
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
-
Difficulty 1/5 Under an hour Newbie friendliness 78/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
bancolombia/sentinel#23 ·
-
test md OpenCI
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
-
integration:quickjs org:external priority:backlog topic:code-interpreter topic:middleware type:feature
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
langchain-ai/deepagents#6450 ·
-
bug client
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100