[MITgcm-devel] OBCS_SPONGE vs RBCS

[Martin Losch]

Hi Jean-Michel,

I am fine with your suggestions.

Currently I have no immediate plans for extending obcs_calc_stevens to seaice or ptracers.

M. 



On Nov 17, 2010, at 6:06 PM, Jean-Michel Campin wrote:

> Hi Dimitris,
> 
>> On a separate but related topic, I want to implement RBCS for pkg/seaice.
> Good thing.
>> Should the code live in pkg/seaice or in pkg/rbcs?
> I would be tempted to favor the pkg/seaice location (all what is 
> currently in RBCS is for 3-D fields, so would need separated mask anyway), 
> but ptracers is done within pkg/rbcs, so it's not really consistent 
> with what I propose ...
> 
> On similar subject, I was thinking of moving out of pkg/obcs
> the ptracer and seaice parts (in the 1rst step, would keep the
> namelist unchanged, and could see later when parameter files
> would be changed). There are reasons in favor of this move,
> e.g., the pieces in obcs_init_variables.F are not right
> with PTRACERS_Iter0 > 0 ; + splitting obcs_calc would make it
> more flexible on where/when to call it.
> It's not urgent, but it would be a good thing to agree on this 
> (moving or not) before extending OBCS-STEVENS to seaice & ptracers.
> Do others agree ?
> 
> Cheers,
> Jean-Michel
> 
> On Wed, Nov 17, 2010 at 06:48:30AM -0800, Menemenlis, Dimitris (3248) wrote:
>> Jean-Michel, I agree that it would be cleaner to incorporate in RBCS capability for U & V and to remove OBCS_SPONGE.
>> I was actually going to email you about problems that Michael had with OBCS_SPONGE since modif before last
>> in his PIG setup but you preceded us by checking in a fix.  But OBCS_SPONGE is still problematic because of bathymetry
>> and corners as you describe.  So I definitely vote for moving OBCS_SPONGE to RBCS.
>> 
>> On a separate but related topic, I want to implement RBCS for pkg/seaice.
>> Should the code live in pkg/seaice or in pkg/rbcs?
>> 
>> Dimitris
>> 
>> Dimitris Menemenlis <menemenlis at jpl.nasa.gov>
>> Jet Propulsion Laboratory, California Institute of Technology
>> MS 300-323, 4800 Oak Grove Dr, Pasadena CA 91109-8099, USA
>> tel: 818-354-1656;  cell: 818-625-6498;  fax: 818-393-6720
>> 
>> On Nov 17, 2010, at 6:37 AM, Jean-Michel Campin wrote:
>> 
>>> Hi,
>>> 
>>> I started to look at OBCS_SPONGE code (see list of comments
>>> below), and would like to propose to drop OBCS_SPONGE
>>> and to add RBCS capability for U & V.
>>> The main reason is that point 1 & 2 (and 6 ?) are inherent
>>> to our obcs-sponge code, and RBCS would solve both in a clean
>>> and reliable way.
>>> What is your opinion on this subject ?
>>> 
>>> Cheers,
>>> Jean-Michel
>>> 
>>> ---------------------------------
>>> There are several reasons that make the OBCS_SPONGE code
>>> difficult to use and to maintain:
>>> 
>>> 1) relaxation towards OB value is tricky when the bathymetry
>>> is not flat in all the sponge layer region + OB section.
>>> In the current Sponge layer, on a wet point, we relax
>>> towards the OB values which might be in land.
>>> 
>>> 2) when 2 OB (e.g., North and West) are close enough to
>>> each other, the 2 sponge layers have an overlap.
>>> And it's become tricky (for a numerical point of view)
>>> to handle correctly 2 relaxation terms towards
>>> different values.
>>> 
>>> 3) there are few run-time parameters that are missing:
>>> - a set of "useSpongeNorth/South/East/West" (can help with point 2).
>>> - a set of "useSpongeT,S,U,V" (This is a problem when
>>> someone wants to use RBCS for T,S and Sponge for U,V).
>>> And it would be a good thing to have the option to specify
>>> different relaxation time scales for U,V and T,S.
>>> 
>>> 4) OBCS-sponge is not tested (partly because of point 3) .
>>> 
>>> 5) The code and documentation need improvements:
>>> - the U and V in UrelaxObcsBound/Inner and VrelaxObcsBound/Inner
>>> are not related to U/V velocity (as described in OBCS.h) but
>>> related to East/West and North/South OB.
>>> - the thickness of the sponge layer, more precisely, the number of
>>> points where relaxation is applied is not "spongeThickness"
>>> but "spongeThickness - 1".
>>> - the 2 extreme values for relaxation time scale, XrelaxObcsInner
>>> and XrelaxObcsBound are never reached; Instead, the relaxation
>>> time scale is always an interpolated value between those 2
>>> extremes.
>>> - in obcs_sponge.F, lot of single precision computations (results
>>> will change with compiler "-r8" option); not efficient (all relaxation
>>> time-scale calculations could be done once); not very robust
>>> (testing for zero value of Temp & Salt OB values).
>>> 
>>> 6) I don't know if the OBCS_SPONGE code is right when using
>>> CS-grid with OBC that run over on several faces (with switch
>>> between N/S and E/W). I did not check, but the fact that we
>>> need to EXCH (gU,gV) is not a good sign.
>>> 
>>> That's all for now.
>>> ---------------------------------
>>> 
>>> _______________________________________________
>>> MITgcm-devel mailing list
>>> MITgcm-devel at mitgcm.org
>>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
>> 
>> 
>> _______________________________________________
>> MITgcm-devel mailing list
>> MITgcm-devel at mitgcm.org
>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
> 
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel