[MITgcm-devel] OBCS_SPONGE vs RBCS

[Menemenlis, Dimitris (3248)]

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