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

[Martin Losch]

To be honest, I can't remember, why obsc_apply_ptracer/ts/tloc/sloc  
use the velocity point masks. I have a faint recollection that there  
was a good reason, but maybe the original author of obcs can help out?
Currently, the I see these reasons:
1. it does not make sense to have a wet point (on the open boundary)  
outside of a dry point, there will be no impact on the solution, just  
problems
2. ideally, we should be applying fluxes across the boundary, rather  
than resetting the open boundaries all the time, maybe this notion  
has something to do with it?
3. what is the correct value for say ptracers(iobc) if ptracers 
(iobc-1)=land (the current default boundary conditions are v.Neumann,  
so (ptracers(iobc)-ptracers(iobc-1))=0; the same is probably true for  
orlanski, which gives you the ultimate reason for the "grad 
(topography)=0 acoss open-boundarie" condition)

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.

If that's agreeable, I can put in that fix.

Martin
On 12 Apr 2008, at 03:09, Dimitris Menemenlis wrote:
> Martin, as a general comment for this tracer obcs mask problem, we  
> already had a very similar discussion thread last July because of  
> seaice:
> http://forge.csail.mit.edu/pipermail/mitgcm-devel/2007-July/ 
> 002898.html
> In particular, the following message describes why resetting T/S to  
> zero at boundaries caused sea-ice to blow up:
> http://forge.csail.mit.edu/pipermail/mitgcm-devel/2007-July/ 
> 002900.html
> similar to the tracer package blowing up when tracer value is set  
> to zero.
>
>> I am trying to write code for the check of topography as suggested  
>> on the
>> support list. Basically the check works better than expected:  
>> verification/seaice_obcs is set up as a bad example with non-zero  
>> topography
>> across the open boundaries.
>
> I don't understand why one should not be able to specify boundary  
> conditions at locations where there is a gradient of topography  
> across the open boundary: seaice_obcs appears to work OK.  If it is  
> a problem, however, then it would be preferable for the obcs  
> package to modify the bathymetry as needed outside the open  
> boundaries rather than issue a warning and stop.  The seaice_obcs  
> is carved out of lab_sea experiment.  You are almost guaranteed  
> that this gradient-condition will occur for any arbitrary calving  
> of a regional domain from a larger integration.  Would that be a  
> difficult modification?  If you tell me exactly what is needed I  
> can try my hand at it (but blindly because I do not fully  
> understand how obcs works).
>
>> (also is has some advection/timestepping options that lead to a  
>> warning, also
>> not a good example, unless you want to test this check).
>
> Ooops!  What exactly is the advection/timestepping problem?  I need  
> to make sure that I am not using it for our ongoing Arctic tests  
> (sigh!) or for the cubed-sphere integrations.
>
>> Do you want to fix this experiment, or would you like me to do it?  
>> Having
>> said that, I'd rather not, because I am very likely to miss  
>> important points
>> of this experiment.
>
> Again, if possible, I would prefer to fix pkg/obcs to handle  
> arbitrary bathymetry (by changing it outside the obcs region)  
> rather than change the bathymetry of seaice_obcs.
>
> D.
>
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel