[MITgcm-support] obcs balance

[Martin Losch]

hi there,
Thanks for finding this bug.
I will have another look at the code and fix the domain bounds for  
the balancing, however, it's strange, that this code still give no  
satisfying balance. Can you verify, that this is only due to the  
truncation error (total volume flux across boundary per timestep x  
1e-14 x number of timesteps / area of domain or so should give you an  
estimate of that).

Otherwise try Dimitris' matlab code for offlline balancing (from his  
recent email):
> Chuncheng, you can look at
> http://ecco2.jpl.nasa.gov/data1/arctic/run_template_cube81/ 
> mk_run_template.m
> for an example of balancing boundary conditions offline.  Search  
> for "balance BCs".
> When I do that, I find that mean sea level remains balanced.  Dimitris


Martin

On 6 Jan 2009, at 03:53, 名 徐 wrote:

>  Dear Martin
>       I had follow your suggestion to make I=1,sNx and J=1,sNy.The  
> sea level descend 0.5m after ten years integrated.This result has   
> a major improvement than before,but the
> question still has't been decided .The major cause I think is the  
> truncation error of computer been cumulated after ten years  
> integrated.So I think,one method is plus extra velocity in open  
> boundary afer some calculate steps for counteracting the integral  
> error .Another is  minus the sea level  raise or descent mean afer  
> some calculate steps.Which routines I can
> do it for the modify ?Also ,would you tell me other good idea for  
> this?
>
>
> --- 08年12月19日，周五, Martin Losch <Martin.Losch at awi.de>  
> 写道：
> 发件人: Martin Losch <Martin.Losch at awi.de>
> 主题: Re: [MITgcm-support] obcs balance
> 收件人: mitgcm-support at mitgcm.org
> 日期: 2008,1219,周五,3:48下午
>
> Dear 名 徐, the routine where the open boundary conditions are set  
> is obcs_calc.F. At the bottom of this routine, you'll find the code  
> that does the balancing. I have never used that part of the code  
> and now that I look at it, it seems strange that the loop ranges of  
> the loop for the calculation of the average flux (the first loop in  
> each section), to be substracted from the velocity field in the  
> second loop, range from I=1-Olx,sNx+Olx (for north/south) and J=1- 
> Oly,sNy+Oly (for east/west). Naively I would think that they should  
> range only over the computational domain *without* the overlaps, so  
> I=1,sNx and J=1,sNy, but I may have overlooked something. So please  
> try this, and let us know, this may be a bug in the code.  
> Alternatively you can balance your velocity fields offline, i.e.,  
> before you prescribe them. That's what I normally do. This way you  
> can make sure that your fields balance over the period that you  
> want, e.g. a tidal cycle, a day, a week/month/year/decade (I guess  
> it's a year in your case).  Martin On 19 Dec 2008, at 03:23, 名 徐  
> wrote: > Dear: > I had set exactConserv=.true. in data (PARM01),but  
> it seems that the result had not a major improvement. > Also ,I had  
> the tests as you showed.The sea level hardly raised if all  
> boundaries had been close or did not prescript the velocities  
> normal to the boundaries.Meanwhile,I had another test.If only the  
> west boundary velocities been prescribed,the sea level hardly  
> raised.But, If only the south boundary velocities been  
> prescribed,the sea level evidently raised.I think the larger flux  
> of volume caused the sea level raise,beacause the south boundary  
> flux of volume is larger 15.6% than the west boundary flux of  
> volume.As the exp4 the open boundary flux of volume is small,so the  
> sea level hardly raised after ten years integrated. > Also ,I have  
> a question: which routine apply the parameter "obcs balance" or  
> which routine balance the boundary flux of volume ? > > Hi there, >  
> > I've had a quick look through your files. There are a few things  
> you can > try to narrow down the problem: > 1. set  
> exactConserv=.true. in data (PARM01); this should improve the >  
> conservation of volume. > 2. close all of you boundaries (e.g. by  
> creating a topography with a wall at > i=1 and j=1) and see what  
> happens > 3. with the open boundaries turned on, do not prescript  
> the velocities normal > to the boundaries (the default should be  
> zero, so that there should not be any > flux of volume through the  
> boundaries). > > Martin > PS. can you try to reproduce your problem  
> with a smaller domain for faster > integrations (say a 10x20 or so  
> box). that would make debugging simpler for you > and then we could  
> try this on one of our machine and by that help you much > better.  
> > > On 16 Dec 2008, at 10:53, 名 徐 wrote: > > > Thank you for  
> your answer,I have sent the all files you need on enclosure. > >
>
> 好玩贺卡等你发，邮箱贺卡全新上线！
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-support