[MITgcm-devel] Re: [MITgcm-support] obcs_apply_ptracer

[Martin Losch]

The obcs issue is this:
Bad land mask (x=land, +=ocean, o=open boundary points) for northern  
open boundary:
> i=123456789
> 4 ooooooxxx
> 3 +++++xxxx
> 2 +++++++++
> 1 +++++++++
>

good land mask:
> i=123456789
> 4 oooooxxxx
> 3 +++++xxxx
> 2 +++++++++
> 1 +++++++++
>

And this is true for ALL layers. Why?
Because the open boundary point is set according to maskS(I,J_obn),  
the point i=6, j=4 will not be assigned a values, because (6,3) is  
dry and maskS(6,4)=0. This is not a problem, because pint (6,4) does/ 
should not have any impact on the solution in the interior, so I can  
(and should) be a land point, too. This point becomes a problem, if  
you still compute something there, e.g. sea-ice, or surface co2- 
fluxes (as Taka wants to do), then the zero on this point for T/S/DIC  
causes a problem for the rest of the code.
Solutions
1. don't use the bad landmask, but use the good landmask by  
prescribing your topography  accordingly.
2. don't use maskS for deciding if (6,4) should be set or not, but  
maskC.

solution 2 is not a good solution, because the C-point on the  
boundary is not really part of the domain anymore, also as I have  
said earlier, we should think of prescribing the fluxes through the  
boundary (which we currently don't), and then maskS is the natural  
choice. I believe (but don't know for sure), that for Orlanski, one  
actually computes fluxes. The default boundary condition for passive  
tracers is constructed with a flux in mind (v.Neumann condition), but  
prescribed as a Dirichlet condition.

So Dimitris, I do not confirm, the issue is *NOT* that the land mask  
is different for obcs and the rest of the code. The issue is that  
currently the model allows the "bad landmask" without complaining.
Basically one has to avoid hfacc(J_obn)>hfacc(J_obn-1) etc. for each  
layer (or simply R_low(J_obn)<R_low(J_obn-1), by preparing the input  
topography accordingly.

Martin


On 16 Apr 2008, at 14:53, Dimitris Menemenlis wrote:
> I am holding off modifying seaice_obcs until next week so as not to  
> put crap in CVS and then have to overwrite.
>
> My understanding of the obcs issue is the following (Martin please  
> confirm): the landmask used by pkg/obcs is "different" from the  
> landmask seen by the rest of the code.  Most of the time this does  
> not matter but it "does" matter when one is trying to do a tracer  
> or sea-ice computation where T=S=0 causes trouble.
>
> A second reason for holding off on modifying seaice_obcs is that I  
> have suspicion that something is not quite right with lab_sea/ 
> input.salt_plume
> Ever since I added "StaggerTimeStep=.TRUE.," the output of the  
> verification experiment has become even more (rather than less)  
> sensitive to the platform on which it is integrated.
>
> D.
>
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel