1 deg CICE grid very slightly misaligned with MOM

[aekiss]

The 1deg CICE grid values are very slightly different from MOM in both latitude and longitude for both T and U points - see this notebook.

Perhaps there was loss of precision due to conversion to single precision and back to double?

Possibly related: #271

[aekiss]

would be good to have grid sanity checks to catch this sort of thing #129

[anton-seaice]

This should be fixed by writing a tool to generate the CICE grid from the MOM-supergrid, which would also give us known provenance of the CICE grid files. (The tool could go in om3-scripts)

OM3 has some sanity checks (with tolerance set by eps_imesh) but there could be more.

[anton-seaice]

@aekiss - I don't have permissions but I think this should go on the CMIP7 project board.

[anton-seaice]

The CICE grid.nc file needs these variables defined (per ice_grid) :

! (1) ULAT  (radians)    \\
! (2) ULON  (radians)    \\
! (3) HTN   (cm)         \\
! (4) HTE   (cm)         \\
! (7) ANGLE (radians)

I think we can derive all these from the mom supergrid.

Angle is defined as 'ANGLE = angle between local x direction and true east' which is consistent with MOM definition except in radians from -pi to pi. Its not clear which corner of the grid cell this is measured, although it is presumably at the U points (for consistency, and because CICE calculates an ANGLET quantity).

EDIT: More fields are needed than this for OM2, but they can all be derived from the mom supergrid, the right place to look is here in ice_grid

[anton-seaice]

Perhaps there was loss of precision due to conversion to single precision and back to double?

Similarly, it could have been a degrees to radian conversion using a constant with insufficient precision

[aekiss]

Plots of the grid absolute and relative errors are shown in the first part of https://github.com/aekiss/notebooks-MartinDix/blob/d6d147a/grid025_check.ipynb.

The relative error is very nearly constant (7.746366e-9) for all grids, suggesting a differing value of pi in the deg-rad conversion.

For that matter, could it just be because our numpy check uses a slightly different deg-rad conversion factor from cice?

[anton-seaice]

For that matter, it could just be because our numpy check uses a slightly different deg-rad conversion factor from cice.

This looks probably ok:

https://github.com/CICE-Consortium/Icepack/blob/f6ff8f7c4d4cb6feabe3651b13204cf43fc948e3/columnphysics/icepack_parameters.F90#L70

pi = 3.14159265358979323846_dbl_kind

>>> np.pi
3.141592653589793

[aidanheerdegen]

So there is a problem, or not?

[anton-seaice]

So there is a problem, or not?

We should fix this, but the discrepancy is <5e-6 so at most the differences in the results would be rounding error ( I think)

We should definitely fix the 0.25 degree grid.

[anton-seaice]

I deep dived on tarea too, to see what happens and to try and understand how we should be making the cice c-grid. I calculated it from the mom supergrid like this:

tarea = mom_ds.area.coarsen(nx=2, ny=2).sum()

(for sanity, I checked this is the same as mom_ds.area[::2,::2]+mom_ds.area[1::2,::2]+mom_ds.area[1::2,1::2]+mom_ds.area[::2,1::2])

I compared the calculated tarea from the cice file, and the differences south of 65N seem as expected (i.e. in the 14th significant figure).

However, in the tripole region they do become significant (in m^2):

In the cells around the tripole, the difference is >1%. Have I calculated the tarea wrong from the mom grid? Or is the cice file wrong? (The sum of the anomalies is 0)

p.s. FYI @ezhilsabareesh8

p.p.s: I guess it could different areas could be correct but calculated in different ways ... different assumptions about how round the earth is etc, but surely having them internally consistent would be good.