[Feature]: greater flexibility in choosing longitude orientation + swap_lon_axis discontinuity

[pochedls]

Is your feature request related to a problem?

This is part feature request, part FYI (I wanted to document this somewhere). We can move this to the discussion area if that is a better place.

Some models that have grid cell boundaries that are partially outside a strict (0 to 360) or (-180 to 180) domain. For example, a model with longitude values of 0, 1.875, 3.75, ..., 358.125 has a boundary that crossed the prime meridian. In this case the first longitude value has a boundary of -0.9375 to 0.9375 (or 359.0625 to 0.9375).

The spatial averaging (and CDAT) routine breaks this grid cell into two cells with the same value (but different boundaries): one that spans (0 to 0.9375) and another that spans (359.0625 to 360).

I am just noting here that swap_lon_axis does not do this (at least for cells spanning -180/180). Here I provide an example where the number of longitude grid cells is the same after swapping the orientation (and there is an example of a grid cell with a lower bound of 179.0625 and an upper boundar of -179.0625. See below:

# load dataset
dpath = '/p/css03/esgf_publish/CMIP6/CMIP/CSIRO/ACCESS-ESM1-5/historical/r10i1p1f1/Amon/tas/gn/v20200605/'
ds = xcdat.open_mfdataset(d + '*.nc')
print('Original lon bound', ds.lon_bnds.values[0,:], len(ds.lon))
# swap to 180
ds2 = xcdat.swap_lon_axis(ds, to=(-180, 180))
print('Updated lon bound', ds2.lon_bnds.values[0,:], len(ds2.lon))

Original lon bound [-0.9375 0.9375] 192 Updated lon bound [ 179.0625 -179.0625] 192

Note that these grid cell boundaries are correct (but not exactly the same as what CDAT does).

Describe the solution you'd like

In the future, I think it would be useful to give the user more flexibility in specifying longitude domains, e.g., (-90 to 90) or (0, 120) or whatever, instead of only (-180 to 180) or (0 to 360). At that point, it may make sense to ensure the grid cell boundaries are aligned with the user specified domain boundaries (and to repeat grid cell values in the case that the grid cells cross -180/180 or 0/360).

For now, I think we can leave this as is until this functionality is needed since I don't think there is anything wrong with the current functionality.

Describe alternatives you've considered

No response

Additional context

This (grid cells crossing the prime meridian) was something that needed to be handled in spatial averaging because the area weights are calculated from the grid cell boundaries. I'm not sure this will cause problems in general, though.