Conservative regridding with xESMF -- puzzled because the integrals don't quite agree

COSIMA
1

I’m trying out xESMF to perform conservative regridding.

I have a function defined on a global grid and then conservatively regrid to a different grid.
I compute the integral of the function in the two grids and it’s not the same down to machine precision. I thought that’s exactly the point of conservative regridding.

(Both my grids have exactly the same bounds; they are lat-lon grids that cover the whole globe) and my test-function is compact and does not include pole singularities or weird stuff…

A python notebook is found at:

Any insight is welcomed!

cc @taimoorsohail

[for the record, this is related to conservative regridding in Oceananigans, cf. CliMA/Oceananigans#4782, CliMA/Oceananigans#4818, CliMA/Oceananigans#4819 , CliMA/Oceananigans#4823]

2

Not sure if this is useful (could be totally unrelated) but I’ve always had trouble making the conservative regridding method periodic in longitude, even when specifying periodic=True :woman_shrugging: . If you print out your regridder after making it, has it taken the periodic=Trueinto account? If not, could that be contributing to the discrepancy?

3

The xESMF docs mention that periodic kwarg fallsback to False regardless of what you prescribe for conservative regridding. That’s OK though because I provide the bounds of all cells. Also my function (if you glance the gist) is far away from the longitude boundaries so that shouldn’t be an issue.

4

Drawing blanks then, sorry. But intrigued to hear the outcome/solution.

5

for ref: xESMF/xesmf/frontend.py at f2eeeb2071f4f1386dd0852ddb2696568134e387 · pangeo-data/xESMF · GitHub

1 Like
6

My latest guess is whether the areas of the cells in xESMF are not computed exactly how I am computing the areas in the notebook.

The way I am doing it if I add all areas of all cells I get exactly 4πR^2 tho…..

From what I understand also xESMF/ESMF compute areas using an exact formula for spherical geometry polygons so that shouldn’t be an issue. But I don’t know how to read the ESMF code tbh…

7

Hi Navid,
I had a hunch that part of the problem here is that the Gaussian is positive everywhere, and the curved shape gives rise to a systematic bias when cutting the corners of a positive-only input.

So I played around with your example and constructed an alternative, where I have both a positive and negative Gaussian, and a background term of 0.01, then you get a sense of the general magnitude of the summation over a non-zero field. See my modified version of your gist:

Here I get a “relative error” of 1e-16 using your same integral technique, just with somewhat different baselines, and both “positive” and “negative” Gaussian.
My gut feeling is that when integrating over global area, you get a really big number. Then taking a difference of slightly altered integrations yields a difference that is small, but when summed over very large areas appears to be larger…
Basically I think the regridder is fine… it’s just that you’re dealing with extremely large areas in m^2.

8

Another test you could do would be to use a realistic temperature field (maybe a WOA input or something) and compute its average before and after using the regridder. This would also give you a sense of how a real integral would be affected by the remapping.

9

Thanks! I’ll have a look tomorrow. (Late pm local time)

But quick response: the rel error doesn’t care about how big the numbers are. It’s relative to the original value. So I’m still confused. But…! Let me have a deeper look at your notebook and will come back!

Thanks :folded_hands:t3:

1 Like
10

Yeah… I think you might be right. I did actually construct a TS interpolation example and I got relative errors of around 1e-6 to 1e-7 in average SST and SSS. I added that python script to the gist. So yeah, that seems to be about the level of accuracy.