[MITgcm-support] Volume conservation with OBCS

James B. Girton girton at apl.washington.edu
Wed Jul 2 18:44:19 EDT 2008


David,

I ran into some similar issues a few years ago and decided that a  
separate boundary condition was needed for barotropic waves. A  
radiation condition with constant wavespeed applied to the  
depth-average velocity at the boundary seemed to work pretty well in  
holding down SSH changes. In case you want to check them out, my  
modified versions of a couple of subroutines (especially  
orlanski_west.F since my outflow was on the western boundary) are in:
	http://charybdis.apl.washington.edu/~girton/mitgcm
(Sorry, this never made this into mitgcm-contrib.) I haven't run these  
in a while so I'm not sure whether they are compatible with the latest  
MITgcm code. At a minimum you'd want to tune the wavespeeds to match  
your water depth and/or stratification.

-James

On Jul 1, 2008, at 6:43 AM, mitgcm-support-request at mitgcm.org wrote:
>
> From: David Hebert <david.hebert.ctr at nrlssc.navy.mil>
> Date: June 30, 2008 12:57:29 PM PDT
> To: mitgcm-support at mitgcm.org
> Subject: [MITgcm-support] Volume conservation with OBCS
> Reply-To: mitgcm-support at mitgcm.org
>
>
> Dear all,
>
>  I am trying to simulate a flow over sumberged mountains. I have set  
> up my simulation so that the western boundary is prescribed with a  
> constant velocity (0.1 m/s), and the remaining boundaries are  
> orlanski. I am also using the exactConserv flag for free surface.  
> Also, I use exf to start the simulation from rest and ramp up the  
> boundary over one hour.
>
>  My question is that my surface height, eta, rises unrealistically to  
> 25m after 5 hours of simulation. It seems that I have flow coming in  
> the domain, but not out. Is there something in the orlanski boundary  
> condition that would cause this? I have set the CMAX to 0.49 and  
> cVelTimeScale to 40.0, which is 10 timesteps. 
>
>  Any help/advice from experienced users is greatly appreciated.
>
>  Thanks,
>
>  David
>
>
>
> From: Martin Losch <Martin.Losch at awi.de>
> Date: July 1, 2008 12:48:54 AM PDT
> To: mitgcm-support at mitgcm.org
> Subject: Re: [MITgcm-support] Volume conservation with OBCS
> Reply-To: mitgcm-support at mitgcm.org
>
>
> Hi David,
>
> not that I am an expert on the Orlanski-BCs in the code, but I don't  
> think that there is anything in them that ensures exact conservation  
> of total volume. So before the flow reaches the eastern boundary,  
> there is probably no outflow (can't you check that from the content of  
> state.*.nc (dumpFreq > 0. ) or any other diagnostics that you are  
> using?).
>
> I don't know the size of your domain, but I estimated this: if the  
> domain is (lx,ly,lz) = (50km,20km,1km), then 5h of inflow of 10cm/s  
> would give a volume increase of 3.6e10m^3, corresponding to 36m of SL  
> rise. Probably you did something similar to estimate your expected SL  
> rise in the case of no outflow.
>
> This is what I would try:
> 1. sanity check: turn off orlanski, initialize your entire domain with  
> u=0.1, v=0. and have u_west=0.1 inflow and u_east=0.1 outflow. Along  
> northern and southern boundaries specify v=0.1; (this is similar to  
> verification/exp4). With this configuration (if your topography if  
> constant along the open boundaries), you should not have any SL-rise.
> 2. everything (especially the homogeneous initialization) the same as  
> 1. but turn on orlanski in the east, and see what happens.
> 3. there are flags in the code (see end of obcs_calc), that make the  
> code balance each of the 4 OB inflows indiviually (that is no net  
> inflow at each of the OBs). That's not what you want, but you could  
> modify this code to enforce a global balance, at the cost of breaking  
> the orlanski "dynamics" along the boundaries.
>
> Martin
------------------------------------------------------------------------ 
---------------
James B. Girton, Ph.D., Oceanographer
Applied Physics Laboratory, University of Washington
1013 NE 40th Street, Seattle, WA 98105-6698
206-543-8467 (office) 206-353-4980 (cell) 206-543-6785 (FAX)
SMS: 2063534980 at tmomail.net
------------------------------------------------------------------------ 
---------------





More information about the MITgcm-support mailing list