[MITgcm-support] Logarithmic decrease in Eta without OBCS/EXF
Trivedi, Arjav
arjav.trivedi09 at imperial.ac.uk
Mon Jul 14 10:15:52 EDT 2014
Hi everyone,
Thank you all for your advice/information regarding this issue. I retried my initialisation experiment (the one outlined in my original e-mail; no OBCS/EXF and just the realistic initial temp, sal, U and V initial conditions), but this time with a new bathymetry that had a wall at the Northern boundary as per Jean-Michel's advice. I also performed a similar simulation concurrently that had walls at all N/S/E/W boundaries as well, as per Matt's advice as well. After a number of days of job-queuing and server maintenance, the good news is that both runs ended successfully and when checking the STDOUT files, I had dynstat_eta_mean = O(E-17), which seems to show that there is a conservation of fluid in my domain down to LIGO interferometer scales at least! Having compared these runs to my earlier runs without walls, moving forward now it is apparent I will need to include walls at the boundaries (at least a Northern wall) if I want to keep water from 'leaking out' in the case of a spherical grid.
Given that I wish to use OBCS to force my model boundaries, I am now concerned as to how I would go about this. A few of my concerns are:
1) How would I put in walls and OBCS - e.g. for a Northern wall + OB would I put a wall at j=1 in bathyFile and then set OB_Jnorth(2) = -1?
2) How can I ensure there is realistic outflow of water at the boundaries, without the walls producing spurious reflection/wall effects?
3) (General OBCS question) How can I accurately model inflow such that incoming information forced by the boundary conditions is not prematurely communicated to an inner portion of the domain, that is, there is no 'faster than gravity wave' propagation of information (I hope this question makes sense?)
4) From that I've noticed, a full OBCS boundary wall of data overrides the existing topography (whereas normally in hydrogThetaFile etc. a domain full of data at all grid points will be overridden where there is topography). How can I instruct the OBCS package to continue to respect the topography even when I have put in an OBCS boundary - is this possible, or will I have to change my forcing data sets to match the topography in the correct locations and there set the data values for grid points to zero? If I leave it as is (or even change the points to zero T/S/U/V as I just mentioned), will I get spurious transport along these regions in the open boundary and the regions of real water forcing?
As I am at the formative stages of learning about ocean models I am not sure how naïve these questions are, but any advice/guidance/help in relation to the MITgcm or otherwise is much appreciated.
Thanks very much,
Arjav
-----Original Message-----
From: mitgcm-support-bounces at mitgcm.org [mailto:mitgcm-support-bounces at mitgcm.org] On Behalf Of Trivedi, Arjav
Sent: 09 July 2014 16:58
To: mitgcm-support at mitgcm.org
Subject: Re: [MITgcm-support] Logarithmic decrease in Eta without OBCS/EXF
I will try this and get back to you with the results.
Thanks,
Arjav
-----Original Message-----
From: Jean-Michel Campin [mailto:jmc at ocean.mit.edu]
Sent: 09 July 2014 16:37
To: mitgcm-support at mitgcm.org
Subject: Re: [MITgcm-support] Logarithmic decrease in Eta without OBCS/EXF
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 where 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