Lambda-binning with consistent treatment of boundaries

[hdrake]

I am concerned that the way we are treating (vertical) boundaries in the current implementations of the lambda-binning (e.g., using the xgcm.Grid.transform method) are not robust. First, the xgcm.Grid.transform(..., boundary="extrapolate") keyword argument has been deprecated, so now boundary=extend is now the best supported option. Second, it is not clear how appropriate boundary=extrapolate is anyways because MOM6 does not use this kind of extrapolation for discrete computations on their vertical grid.

In any case, these boundary conditions imprint some substantial noise in the near-boundary calculations of the discretized watermass transformations. While the vertical transform/regridding is conservative, the mismatch between the user-input lambda bins and the vertical diagnostic grid results in compensating spurious positive/negative water mass transformations (which have no net effect). When the scalar lambda field is varies in time and space, these errors will manifest on various theta levels and thus could result in widespread noise

See the example tests in this notebook: https://github.com/hdrake/xwmt/blob/0d1c19a137a710eb7dbce35ea6a0c31b41f86b56/notebooks/testing_examples.ipynb.

[hdrake]

While the vertical transform/regridding is conservative, the mismatch between the user-input lambda bins and the vertical diagnostic grid results in compensating spurious positive/negative water mass transformations (which have no net effect).

Actually, these errors are not even always compensating, and can just straight up bias the results. E.g. the latter two examples produce water mass transformations that are biased high: https://github.com/hdrake/xwmt/blob/53d9a8afda70993f082ec59a00aff8918f74dd40/notebooks/testing_examples.ipynb

[gmacgilchrist]

This is a very useful test case.

I'm still trying to get my head fully around how the extrapolate (or extend) could be the source of this error. Is it best understood as the fact that the extrapolation "fills out" a lambda bin that, in the model, would not have been filled out? I wonder what would be the more appropriate strategy to do this in a manner consistent with what's happening in the model. Online, only the lambdas on the tracer points "exists", so any method to fill out the bins is going to introduce an error.

I saw a lot of issues at the lamda boundary when working through idealized cases before. See (the rather messy notebook) here - the noise emerges in the WMT term when using either xhistogram or conservatively remapped coordinates (this was a precursor to xgcm.transform). Do you think this is the same thing, @hdrake (appreciate that this notebook may be a little tricky to interpret)? We suspected it was something to do with the discretization, but had not pinned down where.

[hdrake]

I'm still trying to get my head fully around how the extrapolate (or extend) could be the source of this error. Is it best understood as the fact that the extrapolation "fills out" a lambda bin that, in the model, would not have been filled out?

Yes, I think that's essentially the issue, but I am also still exploring it.

[hdrake]

A related problem is how to deal with formal discontinuities in the watermass transformation framework when the vertical coordinate is not strictly monotonic, which has two distinct parts to it: 1) vanishing lambda gradients and 2) allowing lambda(r) to have multiple values means that information is lost in the binning process.

See the results of the following idealized experiments (w/ analytical solutions for contexts): https://github.com/hdrake/xwmt/blob/f9cb2bc32490b022485a80a60c08c681efea48d7/notebooks/testing_examples.ipynb

The analytical solutions show that the watermass transformations tend towards ±infinity as gradients go to zero. In the discrete world, these manifest as water mass transformation rates of very larger magnitude. It seems as though this can be particularly problematic if the tendency terms also change sign across the region of vanishing gradient, since then there is a discontinuity from a large positive water mass transformation to a large negative water mass transformation.

Anecdotally, however, I sometimes see these large compensating WMT spikes in MOM6 output in regions with low or weak gradients, e.g. WMT in temperature space around 4ºC water in the South Atlantic.

[hdrake]

Upon further examination (see notebook is most recent commit), I actually think the lambda-binning behavior is consistent as long as you think of the resulting water mass transformations as averages over the finite layers that they represent.

The plots in the notebooks above are misleading because I am comparing bin-averaged values from the discretized xwmt calculation against local values from the analytical solution. Since the analytical solutions are strongly skewed near the singularities, their local values at the mid-point of a lambda-bin are much lower than the average over the bin.

Somewhat surprising, these actually still remain rather well behaved when you approach vanishing gradients!

[hdrake]

Given the above https://github.com/NOAA-GFDL/xwmt/issues/39#issuecomment-1530063105, I don't think there is actually a problem with how we are binning. However, I think we should leave this open until we have explored this a bit further and until I have turned these comparisons to analytical solutions to quantitative tests for xwmt.

[hdrake]

Upon further examination (see notebook is most recent commit), I actually think the lambda-binning behavior is consistent as long as you think of the resulting water mass transformations as averages over the finite layers that they represent.

Following up on this, it is fairly straight forward to analytically average the exact analytical solution for the local water mass transformations within the target grid bins. This allows for a 1-to-1 comparison between the discrete xwmt solution and the exact finite-volume averages. This is done in the updated notebook: https://github.com/hdrake/xwmt/blob/e23fff39d3dbb512530ab40d39437050b63f5025/notebooks/testing_examples.ipynb