[MITgcm-devel] OBCS_SPONGE vs RBCS

[Jean-Michel Campin]

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