[MITgcm-support] Logarithmic decrease in Eta without OBCS/EXF

Jean-Michel Campin jmc at ocean.mit.edu
Wed Jul 9 20:16:27 EDT 2014


Hi Matt,

I am not sure about this:
> If you are planning on using obcs you may as well put a wall around your domain
In particular, if I am using the default "no_slip_sides=.TRUE.",
I have the impression that the results will be different
with or without a wall just beyond the OB.
For instance, with OBC at western side at i=1 (OB_Iwest=1), 
if I try to close the domain by adding a wall at i=1, I will
get friction term coming from the side drag for vVel(i=2);
whereas without a wall, I will not get any sidedrag there.

And an other detail:
I tend to recommend the use of pkg/rbcs instead of the sponge option of pkg/obcs
(except may be when using the OBCS-control with the adjoint):
a) the spacial distribution of the relaxation time-scale is more flexible
 with pkg/rbcs (a 3-D mask is loaded from a file).
b) next to the intersection of two OB (e.g., Southern and Western),
 the 2 sponge regions (associated with each of the OB) will overlap
 and might produce some unexpected results.

Cheers,
Jean-Michel

On Wed, Jul 09, 2014 at 09:02:16AM -0700, Matthew Mazloff wrote:
> Hi Arjav
> 
> If you are planning on using obcs you may as well put a wall around your domain and break the periodicity. This will ensure volume conservation when obcs are off. When you turn on obcs the values just inside the wall will be set to the prescribed value.
> 
> Obcs are tricky -- getting the transports to exactly match takes some care, but it can be accomplished -- you need to use correct hFacs if you are using partial cells. Making sure the flow looks reasonable also takes care. I recommend:
> 1) using a restoring "sponge" layer -- where U and V are restored to the precribed value
> 2) have the bathy gradient normal to the wall = 0 in the sponge
> 3) setting tangential velocity along the boundary to 0 (unfortunately its the only way to have no prescribed divergence -- this is the reason for 2 as well)
> 4) making the corners in the sponge layer have depth 0
> 
> Let me know if you want any more guidance on obcs 
> 
> Matt
> 
> 
> On Jul 9, 2014, at 8:37 AM, Jean-Michel Campin <jmc at ocean.mit.edu> wrote:
> 
> > Hi Arjav,
> > 
> > Sorry, I was not clear.
> > 
> > On Wed, Jul 09, 2014 at 02:16:52PM +0000, Trivedi, Arjav wrote:
> >> I thought the boundaries were periodic in the default cause, i.e. no open boundaries, so what goes out comes back in? Furthermore in my experiments 5) below I didn't initialise with any currents.
> > You are right, but having the same velocity at the Northern edge (i.e., j=Ny+1)
> > as at the southernmost grid point (i.e., j=1) does not ensure an equal transport 
> > with lat-lon grid (since dxG is different). There might be also other issues
> > with coriolis being different at j=1 & j=Ny+1.
> > 
> > When you are running without OBCS, If you did not put a N or S wall
> > in the bathymetry file, could you repeat one of the test with a 
> > N or S wall in the bathymetry ?
> > 
> > Cheers,
> > Jean-Michel
> > 
> >> 
> >> In the OBCS case I am aware that could be the problem, and I have calculated and I've noticed some positive divergence of flow but at the moment I'm finding the problem is in the default, periodic case.
> >> 
> >> Apologies if I've misunderstood the question.
> >> 
> >> Arjav
> >> 
> >> From: michael schaferkotter [mailto:schaferk at bellsouth.net]
> >> Sent: 09 July 2014 14:39
> >> To: Trivedi, Arjav
> >> Subject: Re: [MITgcm-support] Logarithmic decrease in Eta without OBCS/EXF
> >> 
> >> sounds like the initial transport through the open boundaries is negative.  did you calculate that?
> >> 
> >> michael
> >> 
> >> 
> >> On Jul 9, 2014, at 8:23 AM, Trivedi, Arjav wrote:
> >> 
> >> 
> >> Dear all,
> >> 
> >> I am trying to study regional ocean dynamics in the Faroe-Shetland Channel using the MITgcm, with model boundary/initialisation forced from HYCOM data and an atmospheric forcing from WRF. I have been trying to systematically work up to this (though in reality leapfrogging back and forth somewhat), and along the way have an encountered a problem whereby the default model (without OBCS and EXF packages running, so doubly-periodic boundaries) has a decreasing and solely negative sea surface height anomaly. To me this is worrying as it implies that the model is losing water, which it should not in its default state with periodic boundaries. In building up the model I have ran the model many times in various manners to try and isolate the problem. I have come up with the following progression below highlighting the nature of my problem. All runs have been for 2 weeks model time = 1209600s, and run on a 288x288 spherical grid (approx. 2km resolution) with 35 vertical levels and a linear free surface, except whe
> re 
> >> stated.
> >> 
> >> 1)      In .data: bathyFile given, hydrogTheta/SaltFile not given, tRef/sRef taken as initialisation at 10°/35.0. No other forcings/initialisations. No OBCS or EXF.
> >> o   Result [Good]: No decrease in eta, constant throughout at 0m.
> >> o   Notes: As it should be with no initialisation and a constant temperature/salinity basin.
> >> 2)      In .data: Same as 1), except that I have set a constant north-eastwards wind forcing at 2Pa (high wind stress). Model run time is 6h = 21600s. No OBCS or EXF.
> >> o   Result [Good]: Eta output has positive-negative range from -0.35m to 0.25m, dynstat_eta_mean is of the order 0.007m after 2 weeks.
> >> o   Notes: ncview shows convergence/divergence of water on the various coastlines given in the bathymetry. Only issue is short model run time might be masking a potential later loss of eta throughout the domain.
> >> 3)      In .data: bathyFile and hydrogTheta/SaltFile given (tRef/sRef set 10°/35.0 for consistency). Temperature and salinity set as passive tracers (tAlpha =sBeta = 0). No other forcings/initialisations. No OBCS or EXF.
> >> o   Result [Bad?]: After about 2.5 days of highly varying Eta (max/min ranges from +/- 1m) difference between max/min Eta decreases so that the mean Eta stabilises (with very small standard deviation) to around -0.07m without further dropping.
> >> o   Notes: After the period of 'instability' the mean Eta stabilises - but shouldn't it stabilise back to zero Eta? Should there even be a period of instability/variance in Eta given that the Temperature and salinity themselves are just passive tracers?
> >> 4)      Same as 3), except temperature is now an active tracer (tAlpha = 2.E-4).
> >> o   Result [Bad]: After 2 weeks of running, eta_mean has dropped to -0.85m, and is dropping logarithmically.
> >> o   Notes: After period of volatility lasting the first day, the logarithmic drop in eta is approximately a 0.7m drop in eta every tenfold increase in time (i.e. eta_mean drops by 0.7m as we go from 10E4 to 10E5 seconds).
> >> 5)      Same as 3), except now temperature and salinity are both active tracers (tAlpha = 2E.-4, sBeta = 7.4E-4).
> >> o   Result [Bad]: Similar result to 4), except the logarithmic drop in eta_min is smaller.
> >> 6)      Same as 5), except now added in initial current files, uVelInitFile and vVelInitFile. [This is the configuration I have given at the bottom of this email]
> >> o   Result [Bad]: Similar to 3,4), except the logarithmic drop in eta_min is smaller, around 0.5m per tenfold increase in time.
> >> 7)      Same as 6) except running with nonlinFreeSurf=4, select_rStar=2.
> >> o   Result [Bad]: Same outcome as 6.
> >> 
> >> I have done a number of other runs with various flags turned on and off, but I felt these to be the most relevant. I have also performed runs with OBCS and EXF turned on, and the loss in eta is much, much larger (over a two week run with OBCS, EXF on I lost close to 45m of water). However based on the mailing list I am aware that this loss could be due to net divergence at the model boundaries with OBCS, so I somewhat less concerned given that I may be able to use OBCS_BALANCE or Orlanski schemes to 'stem the flow'. However if there is loss in the default case I'm a bit more concerned that something is fundamentally going wrong.
> >> 
> >> I would appreciate any solutions, help, guidance, or just ideas (which are inherently more useful than banging one's head on a keyboard).
> >> 
> >> Thanks very much,
> >> 
> >> Arjav
> >> 
> >> 
> >> Input file ./data:
> >> 
> >> # Model parameters
> >> 
> >> # Continuous equation parameters
> >> &PARM01
> >> # Tracer advection
> >> tempAdvScheme=33,
> >> tempImplVertAdv=.FALSE.,
> >> tempVertAdvScheme=33,
> >> saltAdvScheme=33,
> >> saltImplVertAdv=.FALSE.,
> >> saltVertAdvScheme=33,
> >> # Tracer diffusion
> >> implicitDiffusion=.FALSE.,
> >> diffKhT=1.45E-7,
> >> diffKhS=1.E-8,
> >> diffKzT=1.45E-7,
> >> diffKzS=1.E-8,
> >> # Viscosity Parameters
> >> implicitViscosity=.FALSE.,
> >> viscAz=1.E-2,
> >> viscAh=5.E2,
> >> # Equation of state and reference parameters
> >> eosType='LINEAR',
> >> tAlpha=2.E-4,
> >> sBeta=7.4E-4,
> >> tRef=35*10.,
> >> sRef=35*35.,
> >> # Basic physics parameters
> >> rotationPeriod=86400.,
> >> gravity=9.81,
> >> # Boundary conditions
> >> no_slip_sides=.FALSE.,
> >> no_slip_bottom=.TRUE.,
> >> # Sea surface flags
> >> rigidLid=.FALSE.,
> >> implicitFreeSurface=.TRUE.,
> >> nonlinFreeSurf=0,
> >> exactConserv=.TRUE.,
> >> # Solution and I/O parameters
> >> nonHydrostatic=.FALSE.,
> >> readBinaryPrec=64,
> >> # Miscellaneous
> >> # implicitIntGravWave=.TRUE.,
> >> staggerTimeStep=.TRUE.,
> >> &
> >> 
> >> # Elliptic solver parameters
> >> &PARM02
> >> cg2dMaxIters=1000,
> >> cg2dTargetResidual=1.E-13,
> >> &
> >> 
> >> # Time stepping parameters
> >> &PARM03
> >> startTime=0.,
> >> # endTime = 60s x 60m x 24h (=86400s) x 2wks = 1209600s
> >> endTime=1209600.,
> >> deltaT=6.0,
> >> dumpFreq=3600.,
> >> # deltaTmom=12.0,
> >> # deltaTtracer=12.0,
> >> abEps=0.1,
> >> # pChkptFreq=1382400.,
> >> chkptFreq=0.0,
> >> # monitorFreq = Order(dumpFreq)
> >> monitorFreq=1800.,
> >> monitorSelect=3,
> >> &
> >> 
> >> # Gridding parameters
> >> &PARM04
> >> usingSphericalPolarGrid=.TRUE.,
> >> xgOrigin=-9.32,
> >> ygOrigin=57.93,
> >> delX=288*0.0370370370370363,
> >> delY=288*0.0178571428571459,
> >> delZ= 1.18,         1.40,      1.65,      1.96,      2.32,      2.74,      3.24,
> >>                3.83,      4.53,      5.36,      6.34,      7.50,      8.87,      10.49,
> >>                12.41,    14.68,    17.36,    20.53,    24.29,    28.73,    33.98,
> >>                40.19,    47.54,    56.23,    66.51,    78.67,    93.05,    110.06,
> >>                130.18,  153.98,  182.13,  215.42,
> >>                254.80,  301.38,  356.48,
> >> &
> >> &PARM05
> >> bathyFile='../../topog.fsc288',
> >> hydrogThetaFile='../../theta.init',
> >> hydrogSaltFile='../../salinity.init',
> >> uVelInitFile='../../u.init',
> >> vVelInitFile='../../v.init',
> >> # zonalWindFile=,
> >> # meridWindFile=,
> >> &
> >> 
> >> 
> >> ----------------------------------------------------
> >> Arjav Trivedi
> >> 
> >> PhD Student
> >> Space and Atmospheric Physics Group
> >> Imperial College London
> >> Prince Consort Road
> >> South Kensington, SW7 2AZ
> >> 
> >> T: +44 (0) 20 7594 1402
> >> E: arjav.trivedi09 at imperial.ac.uk<mailto:arjav.trivedi09 at imperial.ac.uk>
> >> _______________________________________________
> >> MITgcm-support mailing list
> >> MITgcm-support at mitgcm.org<mailto: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
> 
> 
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-support



More information about the MITgcm-support mailing list