Sea level increases

[AndyHoggANU]

Further to #11 (and possibly related) is that when I switch from z* to adapt in this simulation, we get some pretty big changes in many aspects of the flow. But the most concerning one by far is sea level. It's a little tricky to unpick. For example, ocean.stats gives me this after about 14 years:

6840, 370093.000, 0, En 6.9851868881350403E-03, CFL 0.10485, SL 7.6305E+00, M 1.98450E+20, S 35.0000, T 0.3061, Me 3.49E-07, Se 1.22E-05, Te -1.51E-04

which sea level 7.6 m above the original. But the variable zos doesn't show any change -- I think this is because it is relative to the geoid? Instead, I sum up all the cell thicknesses and look at the height above bottom at a randomly selected location (doesn't matter where):

Here the blue is the z* run while the orange is from adapt. It's pertinent that ocean mass goes up at the same rate, while heat goes down.

Maybe this will be fixed by addressing the halo issues in #11, but maybe it's separate ...

[AndyHoggANU]

This has been fixed by fixing #11. So, I will close. But note that there is a slow (3cm/decade) reduction in SL now ... will need to keep an eye on that.

[AndyHoggANU]

I'm opening this again, because I don't think it's 100% fixed. I've now done a longer 100-year run with the adaptive option switched on, and we continue to lose sea level through this run (see below):

Now, it's only 30 cm over a century, which is much reduced on the 1 m every few years SLR that we had before. But I still think it points to a systematic bug - possible in the way the halo is handled.

For now, we can run and test this scheme adequately. But we probably need to sort this out before we push the adaptive grid to a global configuration.

[angus-g]

I think I'm able to reproduce this in the MOM6 regression tests: it comes down to a difference between symmetric/asymmetric domains. In the symmetric case there is a relative mass error of about 1e-8, but it's more like 1e-17 for asymmetric. This must come down to a difference in indexing somewhere, but I haven't yet figured out where that is!

[AndyHoggANU]

So, are you saying this is an indexing bug which is revealed in symmetric domains? Or are you advocating I make this domain asymmetric (whatever that means)?

[angus-g]

are you saying this is an indexing bug which is revealed in symmetric domains?

Yeah, that's right, from what I can tell. A symmetric domain has an extra velocity point on the bottom/left edges, so all tracer points are surrounded by velocity points. By contrast, asymmetric just matches the indices of the tracer points, so there's a missing velocity point on the very left and very bottom. It feels more "natural" to use the symmetric indexing, but ultimately I don't think it makes a difference, since it should only impact outside the computational domain anyway. Because the AG code does a lot of computing/applying fluxes, it's pretty easy to end up getting the indexing mixed up somewhere!