add metrics to xgcm Grid object

[dcherian]

I've been experimenting with new xgcm metrics functionality set up like this.

ds["cell_volume"] = ds_g.DZT * ds_g.DXT * ds_g.DYT
metrics = {
    ('X',): ['DXU', 'DXT'], # X distances 
    ('Y',): ['DYU', 'DYT'], # Y distances 
    ('Z',): ['DZU', 'DZT'], # Z distances 
    ('X', 'Y'): ["UAREA", "TAREA"], # Areas (unnecessary)
    ('X', 'Y', 'Z'): ["cell_volume"],  # volumes (unnecessary)
}
grid, xds = pop_tools.to_xgcm_grid_dataset(ds, periodic=False, metrics=metrics)

with these tests

# test that metrics make sense
# TODO: xgcm's get_metric loses coords, attrs
for vel in ["UVEL", "VVEL"]:
    xr.testing.assert_equal(grid.get_metric(xds[vel], "X"), xds.DXU.reset_coords(drop=True))
    xr.testing.assert_equal(grid.get_metric(xds[vel], "Y"), xds.DYU.reset_coords(drop=True))
    xr.testing.assert_equal(grid.get_metric(xds[vel], "Z"), xds.DZU.reset_coords(drop=True))
    xr.testing.assert_equal(grid.get_metric(xds[vel], "XY"), xds.UAREA.reset_coords(drop=True))

for scalar in ["TEMP", "SALT"]:
    xr.testing.assert_equal(grid.get_metric(xds[scalar], "X"), xds.DXT.reset_coords(drop=True))
    xr.testing.assert_equal(grid.get_metric(xds[scalar], "Y"), xds.DYT.reset_coords(drop=True))
    xr.testing.assert_equal(grid.get_metric(xds[scalar], "Z"), xds.DZT.reset_coords(drop=True))
    xr.testing.assert_equal(grid.get_metric(xds[scalar], "XY"), xds.TAREA.reset_coords(drop=True))

For this to work, we need DXU, DXT, DYU, DYT, DZU, DZT, UAREA, TAREA to be always available. Is this feasible? (I think #14 and #27 are related).

If this is feasible, it means we could use the generalized div grad and curl that I'm trying to add to xgcm: xgcm/xgcm#187

[jbusecke]

What exactly are you asking for? That we expose the _get_metrics method to the public API?

Couple of comments:

ds["cell_volume"] = ds_g.DZT * ds_g.DXT * ds_g.DYT

You do not have to do that. The metrics module will reconstruct all 'higher-order' metrics from the 'lower order' ones if the high order ones are not available. This needs to be documented better, I think.

More generally I have been thinking about refactoring the autogenerate module and make it an option to interpolate all metrics from existing ones.

[dcherian]

What exactly are you asking for? That we expose the _get_metrics method to the public API?

No. there is currently a pop_tools.to_xgcm_grid_dataset() that returns a Grid object and a dataset with dimension names that let xgcm do its magic.

I am thinking that this function could always set metrics on the returned Grid object but this depends on all those variables (DXU, DXT, DYU, DYT, DZU, DZT, UAREA, TAREA) being defined on the input dataset.

AFAIK POP output isn't very standardized so consistently getting these metric variables is an issue.

So my question is: can pop_tools always auto-infer the necessary metrics?

[jbusecke]

Should we take this to a zoom call really quick? I really want to understand this better?

[dcherian]

https://meet.google.com/qgc-suif-iak

[jbusecke]

Princeton blocks that for some reason. I sent an invite via email.