[MITgcm-support] Behavior of Ptracers at Orlanski boundary

[Yilang Xu]

Hi Martin, 

Thanks very much for your reply. I have been using RBCS to prescribe an area of continuous supply of ptracers following post (http://mailman.mitgcm.org/pipermail/mitgcm-support/2017-December/011372.html), which might not be a perfect solution to mimic salt. However it works to some extent.  

In my experiments, the boundary values would not matter as long as they don't accumulate. By looking at exp4, I realized that I almost forgot RBCS can be used to enforce ptracers decay at the boundary. Let me check the model behavior later. 

Best,
Yilang

On 4/15/19, 04:42, "MITgcm-support on behalf of Martin Losch" <mitgcm-support-bounces at mitgcm.org on behalf of Martin.Losch at awi.de> wrote:

    Hi Yilang,
    
    I am not sure about the combination of your orlanski and rbcs, maybe test if turning off rbcs will help.
    Maybe you can use exp4 as a simple example. I recall that there, the ptracer leaving the domain it actually works quite well and I don’t see, why the orlanski BC should destroy that behavoir. 
    
    Martin
    
    > On 15. Apr 2019, at 08:10, Yilang Xu <yxu at whoi.edu> wrote:
    > 
    > Hi Martin and Jean-Michel, 
    >  
    > Thanks very much for your advice. I set up a test case and add " OBCS_u1_adv_Tr(1) = 1," in data.obcs, but the plot behaves the same as the case does without it. Generally, the problem is that the ptracer starts to accumulate to a large number after it reaches the Orlanski boundary. I am trying to use ptracer to mimic salt. They behave relatively in a similar way except for the cells near the boundary. I have attached a vertical slice of the ptracer for demonstration. 
    >  
    > My current implementation is the same as suggested in the old post (http://mailman.mitgcm.org/pipermail/mitgcm-support/2012-October/008012.html). Ptracer is resotred by RBCS on a small surface area, and " OBCS_u1_adv_Tr(1) = 1," is the only ptracer-related line in data.obcs (but this did not change any behavior). I am wondering what could be improved if I want to advect the ptracer out properly. Implementing Orlanski BC for ptracers could be a choice in the future. 
    >  
    > Thanks,
    > Yilang
    >  
    >  
    > On 4/12/19, 12:03, "MITgcm-support on behalf of Jean-Michel Campin" <mitgcm-support-bounces at mitgcm.org on behalf of jmc at mit.edu> wrote:
    >  
    >     Hi Yilang,
    >     
    >     Did you try, for each passive tracer "iTr":
    >      OBCS_u1_adv_Tr(iTr) = 1,
    >     This will force to use 1rst Order upwind advection-scheme at OB location 
    >     but only in the case of an outflow. This could help the passive tracer to
    >     leave the domain without accumulating.
    >     An example can be found here:
    >      verification/so_box_biogeo/input/data.obcs
    >     
    >     Cheers,
    >     Jean-Michel
    >     
    >     On Fri, Apr 12, 2019 at 09:41:44AM +0200, Martin Losch wrote:
    >     > Hi Yilang,
    >     > 
    >     > I think that your only way out is to change the boundary conditions for the passive tracers. You obviously read this old post. Now you know what I mean by “keep your fingers crossed”.
    >     > 
    >     > As a quick fix, I usually try to use some approximate v.Neumann BC, but that’s already implemented in the example given in the old post <http://mailman.mitgcm.org/pipermail/mitgcm-support/2012-October/008012.html>
    >     > 
    > > If that doesn’t help you’ll probably have to try to implement Orlanski BC’s for passive tracers …
    >     > 
    >     > Martin
    >     > 
    >     > > On 11. Apr 2019, at 21:51, Yilang Xu <yxu at whoi.edu> wrote:
    >     > > 
    >     > > Hi everyone, 
    >     > >  
    >     > > As MITgcm suggests, the implementation of Orlanski OBCS and Ptracers together is not recommended by the current version of the code. Following some previous discussions
    >     > > (e.g., http://mailman.mitgcm.org/pipermail/mitgcm-support/2012-October/008012.html), I comment out the part that stops the model in obcs_calc.F and obcs_check.F. 
    >     > >  
    >     > > As a result, the model behaves well until the ptracer reaches the Orlanski boundary. I notice the occurrence of instability or aggregation of ptracer when it comes near boundary cells. 
    >     > > I wonder if there is any solution to this problem. Appreciate your help. 
    >     > >  
    >     > > Thanks,
    >     > > Yilang
    >     > > _______________________________________________
    >     > > MITgcm-support mailing list
    >    > > MITgcm-support at mitgcm.org
    >     > > http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support
    >     > 
    >     > _______________________________________________
    >     > MITgcm-support mailing list
    >     > MITgcm-support at mitgcm.org
    >     > http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support
    >     _______________________________________________
    >     MITgcm-support mailing list
    >     MITgcm-support at mitgcm.org
    >     http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support
    >     
    >     
    > <ptracers_side_y_-75.9946degree_100days.png><data.obcs><data.rbcs><data.ptracers>_______________________________________________
    > MITgcm-support mailing list
    > MITgcm-support at mitgcm.org
    > http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support
    
    _______________________________________________
    MITgcm-support mailing list
    MITgcm-support at mitgcm.org
    http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support