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

[Jean-Michel Campin]

Hi Martin & Dimitris,

Thing are becoming more clear now (in a previous email
the i/j indices must have been exchanged:
> I tend to agree with your suggestion, that checking the hfacc's and
> stopping the run is a nuisance. It would be better to automatically
> fix the topography in "ini_depth" or "ini_masks_etc" like this:
> r_low(i_obc,:) = rlow(i_obc-1,:) for northern boundaries etc.
so that it was not very clear at the end what you were planning to do.

In short:
Should not be a real problem to call (from  ini_depth.F) a small OBCS_
subroutine that would do the job (removing "dead" points in the OBC
regions, as you proposed). The remaining question is that the 
OB_ indices are not yet set at this stage, but may be this part of
S/R obcs_init_fixed could be move to obcs_readparms.F (but the 2nd 
half of obcs_init_fixed needs to stay there).

Regarding the seaice_obcs, I also noticed that it does not pass
the restart test (see the daily restart test on faulks) It's not 
using Orlanski OBCS, so I would expect it to pass. 
May be could be easier to fix this restart Pb 1rst that 
might also fix part of the high sensitivity issue ?

What do you think ?
Cheers,
Jean-Michel

On Wed, Apr 16, 2008 at 03:44:08PM +0200, Martin Losch wrote:
> 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
> 
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel