Results from the validation case that mimicks the Jamart et al 1986 paper

The images from the paper are here for convenience

@jm-c if you want to take a look

what happens on main?

should you put the test case into the coriolis documentation ?

should you put the test case into the coriolis documentation ?

Good idea! I ll also test on main.

Ok after a lot of digging, I have the suspicion that the solution is very sensitive to the Coriolis scheme, because that is not added to the split explicit solver, so it is fixed in time and iterated upon many times. I guess that if I add the coriolis scheme to the SplitExplicitFreeSurface solver, the differences are way less since the barotropic flow adapts correctly to the coriolis force, making the flow less numerics-sensitive (typically it means pyhsics is more correctly represented)

This PR, therefore, will include a the refactor of the SplitExplicit to include the coriolis scheme in the fast dynamics (if I find out it is indeed relevant)

Regarding the reference for EEN scheme:

from Sadourny, described by Burridge & Haseler, ECMWF Rep.4, 1977

but this was for relative vorticity (and not Coriolis), if I remember well. I can send you the pdf if you want.

Final update, then I think this PR can be merged. I have added two test cases with coriolis-free surface only dynamics (in the validation/coriolis folder). The results are as following:

• Inserting Coriolis in the SplitExplicitFreeSurface does not change the results in both test cases I have investigated (we should keep it in mind though for the future, especially if we want to run super-coarse resolution cases)
• I have implemented transport-based coriolis since it is beneficial for partial cells (defaults to the simple coriolis for grid-fitted bottom)
• The Active-Weighted schemes (Jamart) are beneficial only in the very simple test case of the paper. Whenever there is a more complicated boundary they lead to numerical errors and energy injection given the amplification of the coriolis force. To make sure I didn't do anything wrong in the implementation, I have reproduced the same case with the MITgcm that shows the same exact error amplification of the active weighted schemes (selectCoriScheme=1)

So I would keep the simple EnsthrophyConserving as a default.

All of the Coriolis implementations should provide a scheme property and we should use the same default for all of them; also the implementation should be uniform.

I am not sure there is a point to the active-weighted schemes. It might be better to delete them. I am not sure in what case there is a benefit to the active weighted schemes -- is there a PR which demonstrated this for some case?

We have added these wet-point schemes because we found some benefit (the relevant PRs are #2729 and #4112).
So I think there might be some scope for keeping them, if someone finds numerical noise at the boundaries. We just can change the default because these schemes are not always a net benefit.

I agree with this:

We have added these wet-point schemes because we found some benefit (the relevant PRs are #2729 and #4112). So I think there might be some scope for keeping them, if someone finds numerical noise at the boundaries. We just can change the default because these schemes are not always a net benefit.

I agree with this:

We have added these wet-point schemes because we found some benefit (the relevant PRs are #2729 and #4112). So I think there might be some scope for keeping them, if someone finds numerical noise at the boundaries. We just can change the default because these schemes are not always a net benefit.

PS can we please not call these "wet point" schemes? They do not only apply to ocean modeling. This is why we introduced the terminology "active weighted", because "active cells" generically apply to any fluid.

Just to get all the results in one place...

On 2729, there's a plot that shows the "regular scheme" on the left and "active weighted" scheme on the right:

the active-only scheme is shown on the right and has lower noise.

On 4112 we have

On this PR, there's a result above:

The analyses are not really consistent with one another though. It seems that active-weighted schemes reduce noise in the vertical velocity. But the analysis on this PR which shows spurious noise due to active weighted schemes looks only at horizontal velocity, and moreover is not a "full test" because it does not include momentum advection.

It feels to me like something is missing here.

• Inserting Coriolis in the SplitExplicitFreeSurface does not change the results in both test cases I have investigated (we should keep it in mind though for the future, especially if we want to run super-coarse resolution cases)

Isn't this result specific to some physical parameters that you chose for the test and not a universal result? For example with smaller g or shallow water or very fast rotation, the free surface time-scale can be closer to the Coriolis time-scale. Thus this conclusion does not hold generically, it may hold for Earth's ocean. But then we cannot use this model for other planets or physical situations where the narrow assumptions of the test do not hold. Is there a downside to including Coriolis in the split-explicit solver? this is the more relevant question. I also recommend running validation cases where the Coriolis timescale and gravity wave speed are similar to understand the universality of the conclusion.

For sure it might be relevant for other coriolis parameters / coarser resolutions. We should always keep in mind that we are doing this approximation. The only downside is the more computations we need to do which make the free surface heavier in the time stepping

The analyses are not really consistent with one another though. It seems that active-weighted schemes reduce noise in the vertical velocity. But the analysis on this PR which shows spurious noise due to active weighted schemes looks only at horizontal velocity, and moreover is not a "full test" because it does not include momentum advection.

Yeah it's a typical case of balanced pros vs cons, there is not a universal "better" scheme in this case.
I have added momentum advection in the tests in this PR and it does not change the picture

Regarding Coriolis in borotropic sub-time-stepping (split-expliicit free-surface): There might be an inconsistency on C-grid with immerse BC, where the Coriolis tendency of the barotropic model, which is evaluated from the barotropic transport, does not match the vertical integral of the the baroclinic Coriolis tendency.
This would be an other reason to leave this part aside and address it in an other PR.

The failure on the oneAPI extension does not seem related. I will merge. Let's keep in mind the possible SplitExplicitFreeSurface change where we include the Coriolis term in the free surface solver