[MITgcm-support] Re: MITgcm-support Digest, Vol 74, Issue 10

[Martin Losch]

Hi David,

I can't answer that, let's hope that Jean-Michel has an explanation.

The code stops in config_check.F if you try to run a non-hydrostatic  
model with non-linear free surface. I don't know what happens when you  
remove that stop-statement.
Probably there are additional terms in the eta-equation that have not  
yet been accounted for in the code (I am guessing that  
solve_for_pressure is the place to start).

Martin

On Aug 11, 2009, at 7:43 PM, David Hebert wrote:

> Martin,
>
> Thanks for including obcs_prescribe_read to allow OB?eta files.
>
> My goal is to implement a boundary condition using eta and nonlinear  
> free surface with nonhydrostatic code. In previous postings it has  
> been said that we can not use nonlinear free surface and  
> nonhydrostatic. Where is that limitation in the code?  I don't see  
> anything in update_etah.F or solve_for_pressure.F that looks like a  
> limitation.
>
>
> Thanks,
>
> David
>
>
> On 08/11/09 10:51, Martin Losch wrote:
>>
>> Marcello,
>>
>> I have used your question as a motivation to actually include code  
>> to obcs_prescribe_read that reads OB?eta from files (I did not  
>> touch the Orlanski bit). When you update your local copy the new  
>> code should appear. However, as you can imagine it is not fully  
>> tested, so I would be grateful if you could provide feedback about  
>> possible problems, in case you are going to use this option.
>>
>> Martin
>>
>> On Aug 11, 2009, at 8:46 AM, Martin Losch wrote:
>>
>>> Hi Marcello,
>>> sorry for the incomplete documentation of obcs (I just checked,  
>>> there is actually something useful thanks to Patrick. It used to  
>>> be much worse).
>>> On Aug 10, 2009, at 7:23 PM, Marcello Gatimu Magaldi wrote:
>>>
>>>> I went through the code. Please correct me if I am wrong (very  
>>>> likely) but it
>>>> seems to me that:
>>>> 1) obcs for the ssh are only defined if NONLIN_FRSURF is defined
>>> No, OB?eta are always defined, but for the linear free surface  
>>> they are always zero.
>>>> 2) even if NONLIN_FRSURF is defined OBEeta and similars are:
>>>>  a) put to zero if neither orlanski nor obcs_prescribe are defined
>>>>  b) not even assigned to a value if orlanski or obcs_prescribe  
>>>> are defined
>>>>
>>> I guess, originally obcs_calc.F was meant to be a template for  
>>> specific code for specific experiments; that's why all OB*  
>>> variable are assigned these weird values, so if you believe that  
>>> OB?eta should be different from zero in your case, you can define  
>>> this value in obcs_calc. When we included the useOBCSprescribe  
>>> option (apply values read from a file), we did not care about the  
>>> non-linear free surface, so this part of the code is missing (and  
>>> no warning about that either, that should be added). If you are  
>>> interested in extending the existing code (and even share this  
>>> contribution) to do that we would be more than happy. It shouldn't  
>>> be hard to do.
>>> if you try to run obcs with a non-linear free surface and Orlanski  
>>> you'll find that the model stops with  an error saying that this  
>>> combination is not implemented, so that case it dealt with  
>>> (although not in a satifactory way). Again if you would like to  
>>> improve the code here, that would be great, but that's probably a  
>>> bit more complicated. Than adding eta to the "obcs_prescribe_read"  
>>> code.
>>>
>>> I have even more incomplete code stubs for obcs: Stevens (1990)  
>>> boundary conditions (used e.g. in MOM3 and higher), which are a  
>>> mix of radiation and prescribed boundary conditions. If you are  
>>> interested in that, I can check it in although it's not yet  
>>> complete (only east and west boundaries and NO special nonlinear  
>>> free surface treatment, may actually not be necessary), and you  
>>> can help finishing it.
>>>
>>>> Now I was wondering if this is done on purpose. Don't we always  
>>>> need boundary
>>>> conditions for eta? I am confused since the MITgcm remains  
>>>> different from
>>>> the models cited above because it always solves an elliptic  
>>>> equation for
>>>> ssh. The other models employ the time-splitting technique and  
>>>> they always
>>>> are in need of obcs for ssh and for BAROTROPIC vertically- 
>>>> averaged velocities.
>>>> In these cases, ob conditions reflecting the hyperbolicity of the  
>>>> equations
>>>> solved such as characteristic method or flather conditions can be  
>>>> employed.
>>>> Cannot we do the same for MITgcm?
>>> As far as I understand, the elliptic pressure solver (you'll find  
>>> it in solve_for_pressure) for the LINEAR free surface does not use  
>>> eta on the open boundaries, because it sets cg2d_b/x=0 on open  
>>> boundaries in the same way as on closed boundaries. I am not sure  
>>> but this implies no flow across the boundary by surface elevation.  
>>> This makes sense for closed boundaries; for open bcs it only means  
>>> that there is no flow across or along boundaries due to surface  
>>> elevation. The non-linear contribution is treated as a correction  
>>> to the linear free surface and is applied separately in the  
>>> correction step of the "pressure correction method" that is used  
>>> in the MITgcm.
>>>
>>> Martin
>>>
>>>
>>> _______________________________________________
>>> MITgcm-support mailing list
>>> MITgcm-support at mitgcm.org
>>> http://mitgcm.org/mailman/listinfo/mitgcm-support
>>
>> _______________________________________________
>> MITgcm-support mailing list
>> MITgcm-support at mitgcm.org
>> http://mitgcm.org/mailman/listinfo/mitgcm-support
>
> -- 
> David A. Hebert
> NRC Postdoc
> Naval Research Lab
> Stennis Space Center, MS 39529
> david.hebert.ctr at nrlssc.navy.mil
> Phone: (228) 688-5846
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-support