CICE-Consortium / CICE

Development repository for the CICE sea-ice model
Other
57 stars 131 forks source link

Grid lengths and averaging #653

Open apcraig opened 2 years ago

apcraig commented 2 years ago

Working on the C/CD implementation, a few issues have come up. I've introduced the new N and E grids, have computed dx and dy for those grids, and am working on the averaging "u2t/t2u" methods to go between the grids.

At present, we read ULON, ULAT, HTN and HTE and then compute TLON, TLAT, dxt, dyt, dxu, and dyu as some of the basic prognostic variables. Both the lon/lat and length scales are simply averaged. This leads to an inconsistency in the T and U grids. If we average lon/lat, we need to take into account the sphere when computing the length scales. If we average the length scales, then the equivalent lon/lat are not at the average of the corners. I believe we should average lon/lat then compute length scales taking into account the sphere properly where terms like cos(lat) should be needed. The areas (tarea, uarea) are computed directly as the product of the dx and dy length scales. As a result, the areas are also inconsistent and don't conserve locally. The errors in the length and area scalars may have an impact on the model results and numerics. That is still to be determined. One way to think about this is that the T and U grids are not on the same sphere and one of the grids may not even be a sphere. This error will be greatest at high latitudes, where grid spacing changes rapidly, and on coarser resolutions. This error affects the grid averaging methods (t2u, u2t) as those are based entirely on the t/u areas. The POP model has the same implementation.

I am adding averaging methods to move fields between grids (i.e. u2t, t2u). In extending these methods and adding a unit tester, I noticed another error. The t2u and u2t averaging is basically an area weighted 4 point average. The t2u averager works fine as there are always 4 valid t points surround a valid u point. That is how the u mask is defined. In the opposite direction however, at coastal areas, there will NOT be 4 valid u points surrounding a t point. The u2t averager is not aware of this (there is no masking), so the u2t average will include these invalid points (usually set to zero) in the 4 point average. There are really two issues. One is that land block elimination results in undefined areas at those gridpoints. The second is that fields may be undefined (or zero) at points where there is land. Fortunately, the only place where u2t is used now is in the dynamics in mapping strocnx and strocny. It's unclear whether those values are locally corrupt because they may be unused or the fields may be defined globally. I think it's partly fortuitous that this issue has not created problems.

An improvement in the length scale computation may improve the simulation, improve numerics, and will improve the grid averaging calculation. But the importance is to be determined. The grid averaging could be a bigger issue in the C/CD implementation. In the B implementation, the impact is minor since the error is isolated to coastal regions in an unused or little used part of the dynamics external forcing. If the C/CD solvers require extensive use of grid averaging for prognostic variables, the averager will have to be updated.

In the grid averager unit tester, errors due to the u2t error are significant where a T point borders land block elimination. The unit tester can also measure errors in averaged fields using simple test cases (like a constant field). These tests show that the length scale errors introduce errors of order 1% (3rd digit) in the solution. The impact of that error to the science is not known.

apcraig commented 2 years ago

See also https://github.com/apcraig/CICE/pull/1.

We should be able to use HUS, HUW to improve the grid accuracy. I propose we add a new namelist that allows us to switch back and forth between "old" and "new" grid length computations. In theory, dxe = HUS and dxt=0.5*(HUS(i,j)+HUS(i-1,j)) and that should be better than computations based on HTN. Same for dye and dyt.

eclare108213 commented 2 years ago

@apcraig what's the status of this issue? A lot has been done already - is there still something left to do, e.g. adding an option for alternative grid length computations? Or should we first run some tests to answer the question of how much this matters?

apcraig commented 2 years ago

Nothing has been done. We need to implement and test changes. Lets keep this open and decide priority on this task relative to others.