[MITgcm-support] how to control obcs balance flow ?

Matthew Mazloff mmazloff at ucsd.edu
Tue Apr 29 14:13:33 EDT 2014 

Hello

Yes -- due to intrinsic periodicity and the fact that W is on the west side of the cell for OBCS you should use
hFacW(2,:,:) on the west wall and hFacS(:,2,:) on the south wall

You can use 
 hFacW(end,:,:) on the east wall and hFacS(:,end,:) on the north wall. 

This allows you to control inflow.

It is safer to make flat bathy in the normal direction for at least the two cells at the boundary. If you use obcs_sponge its better to have flat boundary in the normal direction over the whole sponge so as to not drive a bottom divergence. If you are sponging to a non-zero tangential velocity you should be careful and check how large your W is as the divergence of this velocity will not be balanced by a normal flow divergence.

It is fine to choose difference forcing periods for different input fields.

Matt




On Apr 29, 2014, at 10:35 AM, 李志远 <oceanlizy at 163.com> wrote:

> From: LIZHI  <oceanlizy at 163.com>
> >>To: MITgcm Support <mitgcm-support at mitgcm.org>
> >>Subject: Re: [MITgcm-support] how to control obcs balance flow ?
> 
> Thank you for your answer,Martin !  And thank you for your kindness,Jody .
> 
>       I figure out that problem a little more .  but I am a bit confused when I read the letters in the  "MITgcm  support" column  a few years ago ,I find someone met the same question , and from that letter , I guess that  balance flow  should be this : 
> in my case , I have three open boundarys : north , south, and  east   . I read the hfacs file ,hfacs=134*165*37(nx*ny*nz),then I find the south boundary hfacs(:,1,:) does not agree with the real bathymetry at south open boundary ,but hfacs(:,2,:) does ! That is , when I calculate  vFlux = vVel(i,j,k,bi,bj)*hFacS(i,j,k,bi,bj)*dxG(i,j,bi,bj)*drF(k) ,  I should use hfacs(:,2,:) , not hfacs(:,1,:)  ???
> But when I read hfacw file , east open boundary hfacw(134,:,:)  agree with the real bathymetry at that open boundary . So, I should use   hfacw(134,:,:) to calculate   uFlux = uVel(i,j,k,bi,bj)*hFacW(i,j,k,bi,bj)*dyG(i,j,bi,bj)*drF(k)   . Am I right  ???
> I also get from that letter that  in order to get hfacs(:,1,:)  = hfacs(:,2,:) , when I made bathymetry  depth =134*165, I made depth(:,1)=depth(:,2) ;depth(:,164)=depth(:,165),depth(134,:)=depth(133,:)  ,which means there is  no bathymetry gradient  at open boundarys .
> 
> ****  The subject of  that letter   is  " hfac question " ,in 2009 October  .  I do not confirm what I understand  is correct  , some one can give me some advice  ?  Thanks a lot . 
> 
>     By the way , I wonder , in the data.exf file  , whether it is feasible that  the periods of the forcings are not the same , such as  wind force period is 86400s , the heat flux 's period is 2592000s ? 
> and  whether  the period of obcs input files  is not the same as external force  ?
> Because I have daily wind data and daily obcs data ,but I have monthly heat flux ,salt flux data .
> 
> Thank you ,sir  !
> YOURS LIZHI 
> 
> 
> >On Apr 28, 2014, at  3:12 AM, Martin Losch <Martin.Losch at awi.de> wrote:
> >
> >> Hi Li Zhi,
> >> 
> >> all parameters are nicely described in /model/inc/GRID.h, but probably also in the documentation.
> >> 
> >> hFacW/S are the hfac?s as the ?western? and ?southern? face, so at u and v points. The flow through a grid cell face is:
> >> 
> >> uFlux = uVel(i,j,k,bi,bj)*hFacW(i,j,k,bi,bj)*dyG(i,j,bi,bj)*drF(k)
> >> vFlux = vVel(i,j,k,bi,bj)*hFacS(i,j,k,bi,bj)*dyG(i,j,bi,bj)*drF(k)
> >
> >I think Martin means dxG(i,j,bi,bj) in the last eqn, just in case there was any confusion.
> >
> >Cheers,   Jody
> >
> >
> >
> >> 
> >> Martin
> >> 
> >> On Apr 27, 2014, at 4:40 PM, ??? <oceanlizy at 163.com> wrote:
> >> 
> >>> HI ,Martin;
> >>>    I have read the dxg,dyg,hfacc,hfacw,hfacs files . I understand what is the meaning of dxg,dyg,hfacc , but I am not clear what is the meaning of hfacw and hfacs .and I am not sure how to use them to calculate total flow out and flow in the open boundarys .Could you tell me something about it ?  It is really some shame to ask such easy questions , but I really need that .....
> >>> thank  you so much ,sir  !
> >>> YOURS LIZHI 
> >>> 
> >>> 
> >>> 
> >>> 
> >>>>> Date: Wed, 23 Apr 2014 08:35:54 +0200
> >>>>> From: Martin Losch <Martin.Losch at awi.de>
> >>>>> To: MITgcm Support <mitgcm-support at mitgcm.org>
> >>>>> Subject: Re: [MITgcm-support] how to control obcs balance flow ?
> >>>>> Message-ID: <EF678506-3E22-45AA-9C19-72E6CFFCC9C7 at awi.de>
> >>>>> Content-Type: text/plain; charset="utf-8"
> >>>>> 
> >>>>> HI Li Zhi,
> >>>>> 
> >>>>> I agree with Matt, the best choice is to balance the fluxes during preprocessing. It is a bit tricky, because you need to take into account the exact geometry, i.e. the approrpiate dz, dxg, dyg, hFacS, hFacW. So don?t despair, if it doesn?t work the first time around. You also need double precision for the boundary files, as single precision can already give you some sea level change.
> >>>>> 
> >>>>> For completeness: The balancing that you asked about is described here: <http://mitgcm.org/public/r2_manual/latest/online_documents/node236.html>
> >>>>> <http://mitgcm.org/public/r2_manual/latest/online_documents/node236.html#SECTION00731560000000000000>
> >>>>> 
> >>>>> This method balances the net flow at each time step, which may not be what you want.
> >>>>> 
> >>>>> Martin
> >>> 
> >>> 
> >>> 
> >>> 
> >>> _______________________________________________
> >>> MITgcm-support mailing list
> >>> MITgcm-support at mitgcm.org
> >>> http://mitgcm.org/mailman/listinfo/mitgcm-support
> >> 
> >> 
> >> _______________________________________________
> >> MITgcm-support mailing list
> >> MITgcm-support at mitgcm.org
> >> http://mitgcm.org/mailman/listinfo/mitgcm-support
> >
> >
> **********************************
> 
> 
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-support

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mitgcm.org/pipermail/mitgcm-support/attachments/20140429/26aa19f7/attachment-0001.htm>

More information about the MITgcm-support mailing list