[MITgcm-support] rstar coordinates

[Patrick Rosendahl]

Hello Martin,

first of all thank you for the answer! I was pretty much what I assumed 
the model is capable of.

> a) hydrostatic refers to the hydrostatic approximation under which  
> the vertical momentum equation reduces to: dp/dz = -g*rho. If you set  
> nonHydrostatic=.true., you'll have vertical accelerations (dw/dt is  
> nonzero) and in addition to solving for 2d pressure, you are solving  
> a 3d elliptic pressure equation, which makes the integration at least  
> twice as expensive. In general, non-hydrostatic dynamics are required  
> where strong vertical accelerations are necessary, eg. in simulating  
> convective plumes, at horizontal scales <1000m to 100m. See
> http://mitgcm.org/r2_web_testing/latest/online_documents/node20.html
> http://mitgcm.org/r2_web_testing/latest/online_documents/node39.html
> The term hydrodynamic (which is not the same as non-hydrostatic,  
> stupid terminology, I agree) is misleading in this context.

Yes, I mean non-hydrostatic; and in my case, this is needed. Actually, I 
am used to wait forever for results, and this hydrostatic formulation 
was new to me ;) (Of course this formulation makes perfectly sense for 
oceanic applications!)

> b) rigidLid=.false., and implicitFreeSurface=.true.,

> c) correct

> d) r-star works only with non-linear free surface  
> (nonlinFreeSurf=4,select_rstar=2)
> http://mitgcm.org/r2_web_testing/latest/online_documents/node40.html
> and following chapters for more details

> e) no, from model/inc/PARAMS.h:
>
>> C     implicSurfPress :: parameter of the Crank-Nickelson time  
>> stepping :
>> C                     Implicit part of Surface Pressure Gradient  ( 
>> 0-1 )
>> C     implicDiv2Dflow :: parameter of the Crank-Nickelson time  
>> stepping :
>> C                     Implicit part of barotropic flow Divergence  ( 
>> 0-1 )
>
> As far as I can see, setting these two parameters to zero makes the  
> free surface explicit, but not sure. See also:
> http://mitgcm.org/r2_web_testing/latest/online_documents/node41.html

So I guess there is a (non-hydrostatic) pressure-solver missing for 
r*-coords (which is ugly for steep slopes)? That would mean I am stuck 
with the linearized, surface-cell deforming method.
I want to have the non-linear effects of the surface formulation 
simulated as well (but I will do a run for "explicit surface" as well).

@devs:
maybe you can add a message, telling (select_rstar>0 && 
nonlinfreesurf<=0) is not implemented.

> In principle with linear free surface, the surface elevation can have  
> larger amplitudes than the thickness of the surface cell, but that  
> does not make sense. So if you observe that it makes sense to switch  
> to nonlinear free surface with r-star coordinates. Once the r-star  
> coordinates are turned on, the entire vertical grid is scaled with  
> the surface elevation (not just the surface layer).

On this page way down (2.10.2.5)
http://mitgcm.org/r2_web_testing/latest/online_documents/node42.html
I interpret, this problem occurs also with the linearized form (upper 
layer vanishes)?


I would love to be guinea pig for r*-coords with non-hydrostatic. Maybe 
there is an experimental CVS tree?

> Does this help?

Yes, and thanks again!

Best regards,
Patrick

> On 18 Oct 2006, at 13:47, Patrick Rosendahl wrote:
>
>> Hello all,
>>
>> I hope someone can clearify this.
>> a) I want to use hydro"dynamic" code: nonHydrostatic=.TRUE.,
>> b) I want to use free surface: rigidLid=.FALSE.,
>> c) I want to use the linearized free surface (the only one that  
>> works with hydrodynamic): nonlinFreeSurf=0,
>> d) I want to use "high waves" (together with a fine resolution) so  I 
>> use: select_Rstar=2,
>> e) I can toggle the handling of the free surface explicit/implicit:  
>> implicitFreeSurface=.TRUE.,
>>
>>
>> My questions are
>>
>> - without R*-coordinates the largest wave is restricted to the  
>> discretisation in the uppermost layer ?
>> - has R*-switch an effect with nonlinFreeSurf=0 ?
>>
>>
>> The model runs fine, but I dont know how to interpret the eta  
>> values. Is the whole column streched (R*-coords), or is it just the  
>> uppermost layer width?
>>
>> Best regards,
>> Patrick Rosendahl
>>