[MITgcm-devel] OBCS at tile edges

[Jean-Michel Campin]

Hi,

I think the way the OB indices are set-up in the code (obcs_readparams.F)
is not right, because it enforces that an OB point location is owned by one tile only, 
and assumes that, through EXCH calls, the right OB values will propagate to the 
neighbor tiles.

This implementation does not work when Western or Southern OB
coincide with a tile edge, because the "source" tile which hold the field
value that the EXCH will take to copy over to the "target" tile
is different for tracer fields and for the velocity component normal to OB:

Northern Tile "nT" has Southern OB @ vVel(j=1)    , Theta(j=0)
Southern Tile "sT" has Southern OB @ vVel(j=sNx+1), Theta(j=sNx)

and EXCH will copy  vVel(j=1)   from tile nT to vVel(j=sNx+1) on sT
         and  copy Theta(j=sNx) from tile sT to  Theta(j=0)   on nT

The problem has been found when Patrick's visitor was trying to run
a set-up with 'tilted" OB, South+East, with a sequence of 
 ( 2 Southern OB pts + 1 Eastern OB pt ) x n times, like this:
               ___|
           ___|
       ___|
   ___|
  |
and serious problems start to show up when using multiple tiles.

I think that the solution is to drop the assumption that only 1 tile owns 
one OB location, and to allow both Northern and Southern tile nT & sT 
to have this (common) OB location registered in the OB_Js array.
This might not be so obvious when OBC are computed (Orlanski, Stevens)
since they need to be computed correctly on both tiles.

And also, can no longer use zero as null value for the OB index array
(OB_Ie,w & OB_Jn,s).
And since I don't think it's realistic (too many code changes) to change the 
meaning of OB_Iw & OB_Js to correspond to the velocity normal-component index 
(instead of the tracer index) at the OB (this would allow to keep the zero as 
null value), probably better to change the null value to something else 
(out of normal range, like -99, or still within normal array bounds, like -1).

Cheers,
Jean-Michel