[MITgcm-devel] OBCS changes

[Martin Losch]

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