[MITgcm-devel] OBCS changes

[Jean-Michel Campin]

Hi Martin,

Thanks for your comments.

> I remember, that you+I introduced this because it was needed for high-order (>2nd order) advection schemes.
Yes, but I keep changing my mind, adding things and removing them 
later, trying to convince myself that I am moving forward.

And regarding obcs_check_depth:
> Even if it turns out that this fix is not necessary, it does not do any harm, does it?
It might have a side effect at the intersection of 2 OB (but none
of those crossing is tested). For instance E+S (concave interior), 
 OB_Ie(j=2) = 10 and OB_Js(10) = 2.
And I wanted to check if this type of configuration is "safe" 
or problematic.

Looks like seaice_obcs is giving the same results with OBCSfixTopo=.FALSE.,
and with exp4, I am getting small differences (~trucation error) when I
switch on OBCSfixTopo.

Cheers,
Jean-Michel

On Sat, May 14, 2011 at 05:48:26PM +0200, Martin Losch wrote:
> Hi Jean-Michel,
> some comments below.
> 
> M.
> 
> On May 14, 2011, at 3:44 PM, Jean-Michel Campin wrote:
> 
> > Hi,
> > 
> > I am thinking of going through some cleaning (should not
> > change the solution):
> > 
> > 1) obcs_apply_ts & obcs_apply_ptracer:
> > * remove masking: 
> >   I think this is one of the very few places where T,S and tracers 
> >   are masked. Might be a problem (e.g., atmospheric set-up,
> >   potential temp = 0. Kelvin in atm-physics, e.g. Qsat calculation).
> > * just apply the OB value to the OB point (instead of over a band of 
> >   Olx width):
> >   If this is needed, this is not the right place to do it (before EXCH call)
> >   and should be done by calling obcs_copy_tracer after the EXCH
> >   (I left these calls commented out in do_fields_blocking_exchanges
> >    in case). 
> I remember, that you+I introduced this because it was needed for high-order (>2nd order) advection schemes.
> > 
> > 2) replace some obcs_apply with interior-mask multiplication
> >   (continuity, solvers, vertical velocity, eta ...).
> > 
> > 3) OBCSfixTopo: Martin:
> >   Do you still remember of a simple test-case where the call to 
> >   obcs_check_depths (OBCSfixTopo=true) is really needed. 
> >   I would like to do some tests to check which part of the code
> >   has problems with gradient of bathy across OB.
> I cannot remember why the bathymetry should not have a gradient normal to the boundary.  I am guessing that is has to do with horizontal divergence and strong vertical velocities. verification/seaice_obcs definitely has a non-zero gradient, but I do not know if it breaks when you remove the check. Other pathological case are a bathymetry that slopes down towards the boundary, or a wet open boundary point that is next to a land point in the interior. All of these cases are potentially problematic.
> Even if it turns out that this fix is not necessary, it does not do any harm, does it?
> > 
> > 4) (not very soon) split OBCS.h:
> >    OBCS_PARAMS.h
> >    OBCS_GRID.h    ( or: OBCS_INDICES.h ?)
> >    OBCS_FIELDS.h
> >    OBCS_SEAICE_PARAMS.h \
> >    OBCS_SEAICE_FIELDS.h  } or both in 1 file: OBCS_SEAICE.h ?
> >   also could think about splitting OBCS_PTRACERS.h ?
> >    OBCS_PTRACERS_PARAMS.h
> >    OBCS_PTRACERS_FIELDS.h
> >   and rename: ORLANSKI.h to OBCS_ORLANSKI.h
> >   (or merged into OBCS_FIELDS.h & OBCS_PARAMS.h ? )
> > 
> > Comments are welcome.
> > 
> > Cheers,
> > Jean-Michel
> > 
> > _______________________________________________
> > 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