[MITgcm-support] obcs balance

[名 徐]

 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.
> >



      ___________________________________________________________ 
  好玩贺卡等你发，邮箱贺卡全新上线！ 
http://card.mail.cn.yahoo.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mitgcm.org/pipermail/mitgcm-support/attachments/20090106/a4bc833b/attachment.htm>