[MITgcm-support] Volume conservation with OBCS

Thu Jul 3 10:19:52 EDT 2008

Hi James,

Thanks for sharing your orlanski subroutines. For my case it seems a 
larger part of the issue was in the initial condition, as Martin 
suggested. I ran a new simulations with orlanski outflow boundaries as 
before, but initialized my field to the same as my inflow boundary (that 
is, U = 0.1m/s, V=0). That made a big improvement, since there was 
outflow at boundary at t=0. I saw a 4m SSH increase over 24hrs, vs. 25m 
over 5 hrs.

I was hoping that the SSH would be less with orlanski, but a colleague 
here noted that my simulation has different bathymetry at each boundary. 
In particular, my domain is shallower at the flow exit than entrance, 
which reduces x-sec area and would cause a net influx of fluid in my 
domain. I was hoping this wouldn't happen with orlanski, but with an 
ocean with a free surface there is nothing that forces fluid volume 
conservation, hence the SSH rise. I hesitate to run rigid-lid option, 
however, because I want to see if there is any detectable surface 
disturbance from the submerged mountains.

My next step might be to specify boundaries so there is no net flux of 
fluid (again, as Martin suggested before), but put a sponge layer around 
the boundaries to ease transition from inner flow to prescribed 
condition. Has anyone found a good rule of thumb for sponge layer 
relaxation times? I was going to start with a 10 cell layer sponge with 
relaxation of 3 timesteps for each layer. Any advice is certainly 
appreciated.

Thanks,

David

James B. Girton wrote:
> 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
> --------------------------------------------------------------------------------------- 
>
>
>
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-support