Concatenating over 0 degree longitude line

[SCChan21]

Dear All:

I got a question about concatenation (using iris 3.2.1 - one of the defaults in JASMIN) betwen cubes with longitudes using 0-360.

When I try to do that over the lon = 0 line, I will get longitudes like below (i.e. wrapping all the around the globe instead of having 0.125, 2.625... naturally following 357.625):

[1.25000e-01 2.62500e+00 5.12500e+00 7.62500e+00 1.01250e+01 1.26250e+01
1.51250e+01 1.76250e+01 2.60125e+02 2.62625e+02 2.65125e+02 2.67625e+02
2.70125e+02 2.72625e+02 2.75125e+02 2.77625e+02 2.80125e+02 2.82625e+02
2.85125e+02 2.87625e+02 2.90125e+02 2.92625e+02 2.95125e+02 2.97625e+02
3.00125e+02 3.02625e+02 3.05125e+02 3.07625e+02 3.10125e+02 3.12625e+02
3.15125e+02 3.17625e+02 3.20125e+02 3.22625e+02 3.25125e+02 3.27625e+02
3.30125e+02 3.32625e+02 3.35125e+02 3.37625e+02 3.40125e+02 3.42625e+02
3.45125e+02 3.47625e+02 3.50125e+02 3.52625e+02 3.55125e+02 3.57625e+02]

I presume one can "hack" cube.coord('longitude').points doiing a -360 to the lons that are greater than 180 before concatenating. However, is there a better way to do this?

Thanks in advance
SC

[ESadek-MO]

@SciTools/peloton This looks valid to us, could you give a bit more context as to why this is an issue for you and what you'd like doing?
Some people have been able to use intersection to get the range of -180 to 180 via cube.intersection(longitude=(-180, 180)), see here.

[SCChan21]

Dear ESadek-MO,

Thank you for the reply.

The pre-concatenated cubes (i.e. the original netCDF files) have lon starts at 0.0E, so it seems like concatenate trying to "wrap" around the entire globe i.e. the cat cube will do 0-20E (nothing) 120W-0W.

I managed to fix it by:

1. Seperating the cube into two: i) 180.0 > lon > 0.0 ii) 360.0 > lon > 180.0, using extract.
2. Make the former to have lons of 360+(original_value) by i) remove bounds, ii) directly changing the values in cube.coord('longitude').points, and iii) re-guess bounds.
3. Concatenate again.

I can try the intersection trick.

SC

[HGWright]

@SciTools/peloton We agree that this should just work and so something is going wrong. This will be added to our backlog and when we focus on these kind of issues it will be looked into. We are glad you have a workaround for now. Could you please provide us with the file for when we work on this?

Thanks for raising this!

[bjlittle]

@SCChan21 Are you able to provide us with example data that allows us to investigate this issue further for you?

[SCChan21]

Let me try to do that tomorrow. Sorry sometimes I fix and save things quite ad-hoc manner (sorry I should have known better). I will get back to you tomorrow.
Steven

[SCChan21]

Let me know if the following DropBox links work. I have attached a zip file as well, which has alll three individual files.

sample_ncfiles.zip

0E to 10E file:
https://www.dropbox.com/scl/fi/369jz3s0z7u26fuchf4wh/0E_10E.nc?rlkey=ionaciff6268jjp9nv3tkukfs&dl=0

DimCoord : longitude / (degrees)
points: [
0.49999997, 1.5 , 2.5 , 3.5 , 4.5 ,
5.5 , 6.5 , 7.5 , 8.5 , 9.5 ]
shape: (10,)
dtype: float64
standard_name: 'longitude'
long_name: 'longitude'
var_name: 'lon'

10W to 0W file:
https://www.dropbox.com/scl/fi/w4bdh04qk7yakjcg3tpzy/10W_0W.nc?rlkey=5ndqw18pz2ihayscefkpjrcf7&dl=0

DimCoord : longitude / (degrees)
points: [
350.5, 351.5, 352.5, 353.5, 354.5, 355.5, 356.5, 357.5, 358.5,
359.5]
shape: (10,)
dtype: float64
standard_name: 'longitude'
long_name: 'longitude'
var_name: 'lon'

Consquence of concatenation using iris 3.2.1 (via module load jaspy/3.10 on JASMIN):
https://www.dropbox.com/scl/fi/f93mx0j7ivynt9pjg7von/10W_10E.nc?rlkey=apaq2mgcknqslz8o78z3suc0b&dl=0

This gives the following lons:
DimCoord : longitude / (degrees)
points: [ 0.49999997, 1.5 , ..., 358.5 , 359.5 ]
shape: (20,)
dtype: float64
standard_name: 'longitude'
long_name: 'longitude'
var_name: 'lon'

[trexfeathers]

Thanks for the extra detail @SCChan21. This is expected behaviour - from the concatenate documentation:

In order to extend the dimensions lengths, the concatenate process requires input cubes with dimension coordinates that can be combined together into monotonic sequences. The order of the input cubes does not affect the concatenate process.

The only way to form a monotonic sequence from the input coordinates is with the large gap in the middle. If you need a coordinate that spans the meridian then the only way is to use negative numbers; below is our recommended workflow for this:

import iris
from iris.cube import CubeList

cubes = iris.load(["10W_0W.nc", "0E_10E.nc"])
cubes = CubeList([cube.intersection(longitude=(-180, 180)) for cube in cubes])
full_cube = cubes.concatenate_cube()
lon_coord = full_cube.coord("longitude")
print(lon_coord)
print(lon_coord.points)

DimCoord :  longitude / (degrees)
    points: [-9.5, -8.5, ...,  8.5,  9.5]
    shape: (20,)
    dtype: float64
    standard_name: 'longitude'
    long_name: 'longitude'
    var_name: 'lon'
[-9.5        -8.5        -7.5        -6.5        -5.5        -4.5
 -3.5        -2.5        -1.5        -0.5         0.49999997  1.5
  2.5         3.5         4.5         5.5         6.5         7.5
  8.5         9.5       ]

(Monotonicity is an important part of a DimCoord as it allows a lot more mathematic assumptions, giving Iris more functionality)

[SCChan21]

Thank you for the clarification.

I guess the question would be then be if concat should be adjusting the dimcoords automatically if it detects a pontential meridian problem, but I can understand cautiousness against doing that (i.e., changing data automatically).

A compromise is to throw a warning if that appears to be the case.

Steven

[trexfeathers]

From @SciTools/peloton: we can see where you're coming from @SCChan21, however we're reluctant to implement anything like this because it's specific to this use case.

These situations come up a lot in Iris, where something is an obvious convenience for many users, but would also undermine/confuse many other users who are performing different operations. For now, we feel it is best to rely on the existing documented behaviour and to answer questions like this as they come up.

[SCChan21]

It is no worries. Thanks again for looking into this.