[MITgcm-support] Re: OBCS sponge and prescribe code checked in

[Martin Losch]

Hi Patrick,
thanks for the code, in particular for the sponge layer code!
Here come more stupid questions:
1.Shouldn't the call ext_getobcs in obcs_calc.F come after the if  
(useOrlanski???) then, else, endif? If I am not mistaken, then the  
prescribed values of exf_getobcs get overwritten either by the  
orlanski_???? or the alternative (if useorlanski????=.false.). I don't  
know what to do with balance code then, should probably at the very  
end, unless the prescribed values are never supposed to be balanced.
2. need the read-in boundary fields be exchanged? (in  
external_fields_load and all other exf_getforcing routines the forcing  
fields are exchanged) I am aware that there are no exchange routines  
for xz and yz slices, but is it save for more than 1 CPU the way it is  
now? Just asking ...

Martin

On Sep 21, 2004, at 1:38 AM, Patrick Heimbach wrote:

>
> Hi Martin, Uli, and others,
>
> I've just checked in code in pkg/obcs/ that
> * ALLOW_OBCS_PRESCRIBE allows prescibing time-dependent obcs values,
> * ALLOW_OBCS_SPONGE sponge layers
> * ALLOW_OBCS_BALANCE rudimentary balancing of normal barotropic flow
>
> tag is checkpoint55a_post
>
> The stuff I checked in at least doesn't break
> the existing verif.'s that use obcs ;o)
> The code has been / is used in a few open boundary setups,
> it compiles ok, but no guarantee that the merging may have
> broken some of the new stuff.
> Any feedback on bugs, improvements etc are welcome.
>
> One feature/caveat is that the time-dependent prescibe
> runs in conjunction with exf, cal., i.e.
> S/R OBCS_CALC calls S/R EXF_GETOBCS
> If someone wants to volunteer to call
> external_fields_load alternatively, please.
>
> The files read are
> xz files (northern, southern boundary)
> yz files (eastern, western boundary)
>
> I've put a few "template" CPP options and runtime parameter files under
> http://mitgcm.org/cgi-bin/viewcvs.cgi/MITgcm_contrib/heimbach/ 
> obcs_prescribe/
>
> A verif. experiment will hopefully come soon.
>
> -Patrick
>
>
>
> Quoting Patrick Heimbach <heimbach at MIT.EDU>:
>
>>
>> Hi Martin,
>>
>> there is code for sponge layers and code for reading
>> 2D (xz, yz) boundart slices (was part of ECCO).
>> I wanted to merge it with the main code last week,
>> but didn't have time since I also had to catch up
>> with the adjoint (-> c55).
>> Will try it in the first half of this week
>> (remind me ;o).
>>
>> -Patrick
>>
>> Quoting Martin Losch <mlosch at awi-bremerhaven.de>:
>>
>>> Hi,
>>> now the obcs-package has got me. In the global_ocean.90x40x15
>>> experiment, I would like to introduce open boundaries in the south
>>> and/or north to emulate polar regions. Now the simplest and dirtiest
>>> way to do it would be through restoring in external_forcing. But I  
>>> want
>>> to do it the hard and clean way and use the obcs package (o: A few
>>> questions arise:
>>> 1) as a general rule/how-to I start by modifying obcs_calc, so that
>>> after calling obcs_calc, the boundary values at time myTime+deltaT  
>>> are
>>> known. Why myTime+deltaT, why not the current time=myTime?
>>> 2) ALLOW_OBCS_SPONGE: Is there code for sponge layers, or am I
>>> completely responsible for it myself (subroutine  
>>> obcs_sponge_u/v/t/s)?
>>> As far as I know, a sponge layer is not much more than a restoring
>>> zone, correct? If I use a sponge layer (#define ALLOW_OBCS_SPONGE),
>>> will I still have an open boundary? Or in other words: just having
>>> restoring in external_forcing.F is not the same as ALLOW_OBCS_SPONGE
>>> and do the restoring somewhere in obcs_sponge_u/v/t/s, etc? It seems
>>> so.
>>> 3) not quite OBCS, but related. I want to read my open boundary  
>>> values
>>> from a file (in calc_obcs), so I have to create code for that, fair
>>> enough; but because I only want to read one xz-slice, for example,
>>> (there is even an MDSIOREADFIELDXZ, impressive), I have a problem  
>>> with
>>> exchanging the xz-slice, or did I just not find the excange_xz_r?  
>>> file?
>>> Does anyone have experience with this?
>>>
>>> Martin
>>>
>>> _______________________________________________
>>> MITgcm-support mailing list
>>> MITgcm-support at mitgcm.org
>>> http://dev.mitgcm.org/mailman/listinfo/mitgcm-support
>>>
>>
>>
>> --------------------------------------------------------
>> Patrick Heimbach   Massachusetts Institute of Technology
>> FON: +1/617/253-5259                  EAPS, Room 54-1518
>> FAX: +1/617/253-4464             77 Massachusetts Avenue
>> mailto:heimbach at mit.edu               Cambridge MA 02139
>> http://www.mit.edu/~heimbach/                        USA
>>
>> _______________________________________________
>> MITgcm-support mailing list
>> MITgcm-support at mitgcm.org
>> http://dev.mitgcm.org/mailman/listinfo/mitgcm-support
>>
>
>
> --------------------------------------------------------
> Patrick Heimbach   Massachusetts Institute of Technology
> FON: +1/617/253-5259                  EAPS, Room 54-1518
> FAX: +1/617/253-4464             77 Massachusetts Avenue
> mailto:heimbach at mit.edu               Cambridge MA 02139
> http://www.mit.edu/~heimbach/                        USA
>