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

Tue Apr 22 14:52:59 EDT 2008

Hi Jean-Michel,

I am confused now. I guess we need to talk about this on the phone. Maybe we can skype tomorrow, after you've got in?

Martin

Martin Losch
Alfred Wegener Institute 
Postfach 120161, 27515 Bremerhaven, Germany; 
Tel./Fax: ++49(0471)4831-1872/1797

----- Original Message -----
From: Jean-Michel Campin <jmc at ocean.mit.edu>
Date: Tuesday, April 22, 2008 8:19 pm
Subject: Re: [MITgcm-devel] Re: [MITgcm-support] obcs_apply_ptracer

> 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
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel
> 