fjp/spherical coriolis

[francispoulin]

I have created a first attempt at this PR to create the SphericalCoriolis as discussed in #4683 with @glwagner.

Note that none of the tests will work because I have not done a global search and replace for HydrostaticSphericalCoriolis for SphericalCoriolis, but I'm happy to do that after we have this set up the way we want. We hope this will not be a breaking change, if done correctly.

In the new script, spherical_coriolis.jl, I currently have an if statement that lets me switch from nonhydrostatic to hydrostatic model. This is not of course what we want but was the easiest thing for me to set up.

Below I have what I think are the two most pressing questions.

Question 1:
What can we use (or create) so that this script can determine whether we are using a nonhydrostatic or hydrostatic model? I am happy to try whatever ideas people think are best.

Question 2:
Can somone look at the nonhydrostatic terms to see if these are completed correctdly? Maybe @simone-silvestri ?

[francispoulin]

@simone-silvestri , I have pushed a few changes and wanted to summarize what I have tried to do.

First, I ignored the energy of enstrophy conserving schemes for now. I thought we can first get the dispatch working for hydrostatic and nonhydrostatic, and then distpach between the two conservative schemes. This seemed easier for me for the moment.

Second, I defined two types in Coriolis.jl: HydrostaticCoriolis and NonhydrostaticCoriolis that we can use to dispatch between.

Third, in the same file, I also defined HydrostaticSphericalCoriolis and NonhydrostaticSphericalCoriolis as you suggested.

Fourth, I changed the averaging operators so f̃w and f̃u are zero in the hydrostatic case.

You pointed out that the term f̃_ℑx_wᶠᶠᵃ and f̃_ℑz_uᶠᶠᵃ are not correct, and I can believe that as I'm still trying to understand the formulation.

In the first term, I was wrong as I was using v instead of w. I fixed that. Is the averaging done incorrectly too?

I'm also not sure what's wrong in the second term but if you can give me a clue I'm happy to investigate.

[simone-silvestri]

This file can be deleted right?

[francispoulin]

Yes, and it is now deleted. Thanks.

[simone-silvestri]

I think this should go in the spherical_coriolis.jl file

[francispoulin]

I just moved those as well.

[glwagner]

Will this work? Whether or not we are using the hydrostatic approximation has to be encoded in a type, which is known at compile time.

[francispoulin]

I can't say that it will work. This was a suggestion that I was trying out.

I think that we need a flag to specify before we define Coriolis or model, that says whether we want hydrostatic or non-hydrostatic, which is not ideal as that is one more thing the user needs to speicfy.

Do you have a different idea on how to do this?

[glwagner]

i propose this API:

hydrostatic_coriolis = HydrostaticSphericalCoriolis()
full_coriolis = SphericalCoriolis()

for implementation, we need a type such that

const HydrostaticSphericalCoriolis{S, FT} = SphericalCoriolis{S, FT, <:HydrostaticFormulation} where {S, FT}

note this preserves the type structure on main so it is not a breaking PR.

one can introduce the concept of the "formulation" like this

struct HydrostaticFormulation end
struct NonhydrostaticFormulation end

struct SphericalCoriolis{S, FT, F}
    rotation_rate :: FT
    scheme :: S
    formulation :: F
end

[francispoulin]

Thanks @glwagner . I'll give this a try and get back to you when I have something together.

[glwagner]

these need to be type aliases, not abstract types

[francispoulin]

I'm happy to change this but maybe best after we decide on how to swtich from one to the other.

[glwagner]

The user will decide which one to use in their script.

[glwagner]

I don't think we need to bother with detecting whether the model is nonhydrostatic or not. I think we should just let the user choose it.

[francispoulin]

I don't think we need to bother with detecting whether the model is nonhydrostatic or not. I think we should just let the user choose it.

I think that's a simple and attracative idea. If the user specifies it then we can choose the Coriolis and model types very easily.

Were you thinking of specifying something like ModelType to be Nonhydrostatic or Hydrostatic? Lots of ways this can go and I admit that I don't have a strong feeling as to what would be ideal for the user. Any suggestions are welcome.

Maybe you were suggesting that we simply pick the Coriolis type to be eieher HydrostaticCoriolis or NonhydrostaticCoriolis ? That makes sense to me and seems that it could work well.

[francispoulin]

@glwagner , I have tried to set things up the way you suggested. Unfortuantely, my programming skills in julia leave a lot to be desired. Could you take a look at let me know if this is what you had in mind?

Also, any suggests on how to clean this up would be greatly appreciated.

It doesn't run now but I think if we can get the structure set up, the calculations should be easier.