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

parse CF-style "bounds" coordinates into xgcm axes #127

Open
rabernat opened this issue Apr 10, 2019 · 6 comments · May be fixed by #568
Open

parse CF-style "bounds" coordinates into xgcm axes #127

rabernat opened this issue Apr 10, 2019 · 6 comments · May be fixed by #568

Comments

@rabernat
Copy link
Contributor

Datasets like this are fairly common:

url = 'https://data.nodc.noaa.gov/thredds/dodsC/ncei/woa/temperature/decav81B0/1.00/woa18_decav81B0_t16_01.nc'
ds = xr.open_dataset(url, decode_times=False)
print(ds)
print(ds.lon)
<xarray.Dataset>
Dimensions:             (depth: 102, lat: 180, lon: 360, nbounds: 2, time: 1)
Coordinates:
  * lat                 (lat) float32 -89.5 -88.5 -87.5 -86.5 ... 87.5 88.5 89.5
  * lon                 (lon) float32 -179.5 -178.5 -177.5 ... 177.5 178.5 179.5
  * depth               (depth) float32 0.0 5.0 10.0 ... 5300.0 5400.0 5500.0
  * time                (time) float32 178.5
Dimensions without coordinates: nbounds
Data variables:
    crs                 int32 ...
    lat_bnds            (lat, nbounds) float32 ...
    lon_bnds            (lon, nbounds) float32 ...
    depth_bnds          (depth, nbounds) float32 ...
    climatology_bounds  (time, nbounds) float32 ...
...

<xarray.DataArray 'lon' (lon: 360)>
array([-179.5, -178.5, -177.5, ...,  177.5,  178.5,  179.5], dtype=float32)
Coordinates:
  * lon      (lon) float32 -179.5 -178.5 -177.5 -176.5 ... 177.5 178.5 179.5
Attributes:
    standard_name:  longitude
    long_name:      longitude
    units:          degrees_east
    axis:           X
    bounds:         lon_bnds

This dataset follows CF conventions on cell boundaries.

It seems like we should be able to automatically parse these coordinates into xgcm axes / grids, with e.g. lon at the center point of the X axis and lon_bnds at the outer point.

@jbusecke
Copy link
Contributor

Great idea. That would help with a lot of observational datasets.
I have used this style of output to calculate static cell depth in MOM5 output as well. There both cells (center and left along axis Z) are given with bounds.
I am wondering: Should xgcm check consistency in such a case?
For example do we want to make sure that the left bound of the center cell is equivalent to the right bound of the left cell?

@jbusecke
Copy link
Contributor

jbusecke commented Oct 1, 2019

This might also be a good fit for the CMIP6 Hackathon, where I assume many tasks will evolve around model validation. Being able to pass observational datasets into xgcm and get a volume/ area weighted sum/average could be very beneficial. I could try to work this into the autogenerate module? And maybe also address the longstanding #79?

@jbusecke
Copy link
Contributor

So I initially tried this here, but it turns out that the vertex coordinate is not always ordered the same way for e.g. the CMIP6 ensemble: Effectively one doesnt know from the index which vertex corner is northeast etc.
This will require some more thinking, but since I realized that the CMIP6 output is quite 'metric-annemic', this issue should move up the priority list! xgcm has most of the ingredients in the autogenerate module to get this done.
This would be a great asset to have for the community!

@github-actions
Copy link

This issue has been marked 'stale' due to lack of recent activity. If there is no further activity, the issue will be closed in another 30 days. Thank you for your contribution!

@github-actions github-actions bot added the Stale label Jun 11, 2021
@github-actions
Copy link

This issue has been closed due to inactivity. If you feel this is in error, please reopen the issue or file a new issue with the relevant details.

siparcs automation moved this from To Do to Done Jun 18, 2021
@jbusecke jbusecke reopened this Jun 21, 2021
siparcs automation moved this from Done to To Do Jun 21, 2021
@jbusecke jbusecke added keepOpen and removed Stale labels Jun 21, 2021
@jbusecke
Copy link
Contributor

I think this is still highly relevant and thus should stay open.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
siparcs
To Do
Development

Successfully merging a pull request may close this issue.

2 participants