[MITgcm-support] instability at Eta

Edward Doddridge edward.doddridge at magd.ox.ac.uk
Mon Mar 7 11:57:56 EST 2016


Hi Kaveh,

It sounds like your open boundary velocities aren’t balanced. If you’re using OBCS you need to make sure that you have as much fluid coming in to the domain as going out, otherwise you’ll be continuously removing or adding fluid from the model.

The OBCS package has some flags for doing this automatically. Check out section 6.3.1.5.6 of this page: http://mitgcm.org/public/r2_manual/latest/online_documents/node236.html

Ed


________________________________
Edward Doddridge
Doctoral Student
Atmospheric, Oceanic and Planetary Physics
University of Oxford

www.doddridge.me<http://www.doddridge.me>

On 7 Mar 2016, at 14:06, mitgcm-support-request at mitgcm.org<mailto:mitgcm-support-request at mitgcm.org> wrote:

Send MITgcm-support mailing list submissions to
mitgcm-support at mitgcm.org<mailto:mitgcm-support at mitgcm.org>

To subscribe or unsubscribe via the World Wide Web, visit
http://mitgcm.org/mailman/listinfo/mitgcm-support
or, via email, send a message with subject or body 'help' to
mitgcm-support-request at mitgcm.org

You can reach the person managing the list at
mitgcm-support-owner at mitgcm.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of MITgcm-support digest..."


Today's Topics:

  1. instability at Eta (kaveh Purkiani)
  2. Re: [SPAM] Re:  Transport through a section (lianzhan at fio.org.cn)


----------------------------------------------------------------------

Message: 1
Date: Mon, 7 Mar 2016 14:51:16 +0100
From: kaveh Purkiani <kavehpurkiani at googlemail.com>
To: mitgcm-support at mitgcm.org
Subject: [MITgcm-support] instability at Eta
Message-ID:
<CA+SSPLAKJkiSpxfCotEuPRi6zY5RkiWSotUfhyx0qBL2+Kemew at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hello everybody,

I have a configuration to simulate the circulation in tropical Pacific
Ocean. It is a simple box model with 20 grid cells in horizontal and
200 in vertical.

Daily averaged temp, salt, u and v velocities are downloaded from
HYCOM. As to OBCS, all the open boundary files are written as
Nx/y*Nz*time format
(here is 20*200*232).

Salinity, temperature, u and v outputs of the model at boundaries are
read correctly by the model. The CFL number (eq.3.28) is extremely
below the
criteria.

As simulation forwards, Eta decreases drastically until I get Nan
values and so negative values for temperature. How to solve this?


Besides that I am having another problem. Although the temperature and
salinity forcing seem to behave as they are, the forcing of the u and
v
velocities are not. In the NetCDF files I get, T and S of dimension 20
* 20, u of dimension 21 x 20 and v of dimension 20 x 21 which
make sense. Therefore, I have two columns of boundary values for U
values at western boundary, similar happens at eastern boundary.
The penultimate column is fine but the next one (last column) is
duplication of western boundary. Similar for V values at Northern and
Southern boundaries happen.
Does this cause an error in reading boundaries? If yes, how to solve
this. I already tried with different OLx and OLy but did not help.

Does anyone have any ideas about what could be my mistake?


below are my data, data.exf and data.obcs files:

# ====================
# | Model parameters |
# ====================
#
# Continuous equation parameters
&PARM01
# tRef= 200*8,
# sRef= 200*34,
implicitDiffusion=.TRUE.,
implicitViscosity=.TRUE.,
viscAr=1.E0,
viscAh=1.E0,
#- put small value (<< stab.limit ~ 3.e10) only to test biharmonic-viscosity
viscA4=1.E8,
no_slip_sides=.FALSE.,
no_slip_bottom=.FALSE.,
diffKhT=1.E3,
diffKrT=1.E-5,
diffKhS=1.E3,
diffKrS=1.E-5,
saltAdvScheme=4,
eosType='LINEAR',
tAlpha=2.E-4,
sBeta =0.E-4,
gravity=9.81,
f0=1.e-4,
beta=0.E-11,
nonHydrostatic=.FALSE.,
rigidLid=.FALSE.,
implicitFreeSurface=.TRUE.,
exactConserv=.TRUE.,
hFacMin=0.2,
readBinaryPrec=64,
nonlinFreeSurf = 4,
# hFacInf=0.0002,
# hFacSup=2.5,
&

# Elliptic solver parameters
&PARM02
cg2dMaxIters=1000,
cg2dTargetResidual=1.E-13,
&

# Time stepping parameters
&PARM03
nIter0=0,
nTimeSteps=288000,
baseTime=0.,
deltaT=10.0,
abEps=0.1,
momDissip_In_AB=.FALSE.,
pChkptFreq=0.0,
chkptFreq=0.0,
dumpFreq=900.0,
monitorSelect=2,
monitorFreq=1.,
# for time dependent open boundary conditions, activate the following 3 lines:
# periodicExternalForcing=.FALSE.,
# externForcingPeriod=86400.,
# externForcingCycle =20044800.,
&

# Gridding parameters
&PARM04
usingCartesianGrid=.FALSE.,
usingSphericalPolarGrid=.TRUE.
ygOrigin=24.5,
xgOrigin=117.525,
delX=20*0.01,
delY=20*0.01,
delR= 200*20,
&

# Input datasets
&PARM05
bathyFile = 'topognew-nobump.bump',
hydrogThetaFile='initial_temp.bin',
hydrogSaltFile= 'initial_salt.bin',
&

data.exf:



# External Forcing Data
# *********************
&EXF_NML_01
exf_iprec         = 64,
useExfCheckRange=.TRUE.,
&
# *******************
&EXF_NML_02
&
# ***************
&EXF_NML_03
&
#
&EXF_NML_04
&
&EXF_NML_OBCS
obcsNstartdate1=20070101,
obcsNstartdate2=000000,
obcsNperiod=86400,
#
obcsEstartdate1=20070101,
obcsEstartdate2=000000,
obcsEperiod=86400,
#
obcsSstartdate1=20070101,
obcsSstartdate2=000000,
obcsSperiod=86400,
#
obcsWstartdate1=20070101,
obcsWstartdate2=000000,
obcsWperiod=86400,
&


data.obcs:


# Open-boundaries
&OBCS_PARM01
# This flag turns off checking and fixing problematic topography across
# open boundaries.
OBCSfixTopo=.TRUE.,
OB_Jnorth= 20*-1,
OB_Jsouth = 20*1,
OB_Ieast = 20*-1,
OB_Iwest = 20*1,
useOBCSprescribe = .TRUE.,
OBNuFile  = 'OB_NorthU.bin',
OBNvFile  = 'OB_NorthV.bin',
OBNsFile  = 'OB_NorthS.bin',
OBNtFile  = 'OB_NorthT.bin',
OBSuFile  = 'OB_SouthU.bin',
OBSvFile  = 'OB_SouthV.bin',
OBSsFile  = 'OB_SouthS.bin',
OBStFile  = 'OB_SouthT.bin',
OBEuFile  = 'OB_EastU.bin',
OBEvFile  = 'OB_EastV.bin',
OBEsFile  = 'OB_EastS.bin',
OBEtFile  = 'OB_EastT.bin',
OBWuFile = 'OB_WestU.bin',
OBWvFile = 'OB_WestV.bin',
OBWsFile = 'OB_WestS.bin',
OBWtFile = 'OB_WestT.bin',
&



Thank you very much for your attention in advance.

regards,

Kaveh.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mitgcm.org/pipermail/mitgcm-support/attachments/20160307/5f920a61/attachment-0001.htm>

------------------------------

Message: 2
Date: Mon, 7 Mar 2016 21:54:52 +0800
From: "lianzhan at fio.org.cn" <lianzhan at fio.org.cn>
To: mitgcm-support <mitgcm-support at mitgcm.org>
Subject: Re: [MITgcm-support] [SPAM] Re:  Transport through a section
Message-ID: <201603072154508437335 at fio.org.cn>
Content-Type: text/plain; charset="utf-8"

Thank you for your reminder. I have made a mistake in last mail, actually I did caculate transport by v(k)*dy(k)*dz(k). And furthermore, the dy is uniform in this case, so I think it is not the key of problem.

With my best regards

Lian Zhan
First Institute of Oceanography (FIO),State Oceanic Administration (SOA),P.R.China
Add: No.6 Xianxialing Road,Qingdao,266061,P.R.China
Tel: +86-532-88967320
E-mail: lianzhan at fio.org.cn

From: Michael Schaferkotter
Date: 2016-03-07 19:37
To: mitgcm-support
Subject: [SPAM] Re: [MITgcm-support] Transport through a section
transport will be velocity times area of face, presumably in this case \sum_{k=1}^km v(k)*dy(k)*dz(k).

Sent from Here3.

On Mar 7, 2016, at 04:03, "lianzhan at fio.org.cn" <lianzhan at fio.org.cn> wrote:

Dear MITgcm users,

I am simulating the  barotropic gyre in an ideal rectangular basin, there is an island in this basin and there is a sill on the left side of the island (the sketch map is shown in attachment). I want to study the transports of water through section A and B (in the north and south of the strait with sill). There two sections , the western boundary of island and the weastern boundary of basin form the boundary of an closed region, therefore the transports through these two sections are suppose to be strictly equal. But they are not, as seen from the result of numerical model. Is it possibly and how could this be? Every suggestion would be greatly appreciated!

I calculate the transport <Catch5AB7.jpg>by: <Catch.jpg>, where the <Catch3834.jpg> is meridinal velocity and dz is the thickness of layers. The number of layers in this model is "km".  And here is my "data" file:


&PARM01
tRef=24*20.,
sRef=24*10.,
viscAz=1.E-4,
viscAh=2.E4,
diffKhT=1.E3,
diffKzT=1.E-4,
f0=0.2E-4,
beta=2.E-11,
tAlpha=2.E-4,
sBeta =0.,
gravity=9.81,
gBaro=9.81,
rigidLid=.FALSE.,
implicitFreeSurface=.TRUE.,
rhonil=1035.,
eosType='LINEAR',
readBinaryPrec=32,
no_slip_sides=.FALSE.,
no_slip_bottom=.FALSE.,
&

# Elliptic solver parameters
&PARM02
cg2dMaxIters=1000,
cg2dTargetResidual=1.E-7,
&

# Time stepping parameters
&PARM03
startTime=0,
endTime=311040000,
deltaTmom=200.0,
# tauCD=172800.,
abEps=0.1,
pChkptFreq=311040000.0,
chkptFreq=311040000.0,
dumpFreq=31104000.0,
monitorFreq=311040000.,
&

# Gridding parameters
&PARM04
usingCartesianGrid=.TRUE.,
delX=500*20E3,
delY=250*20E3,
delZ=5.,5.,5.,5.,10.,10.,10.,10.,20.,20.,20.,20.,50.,50.,50.,50.,100.,100.,100.,100.,100.,100.,100.,100.,
&

# Input datasets
&PARM05
bathyFile='dep_1i_sill_50.bin',
zonalWindFile='taux01.bin',

With my best regards

Lian Zhan

First Institute of Oceanography (FIO),State Oceanic Administration (SOA),P.R.China
Add: No.6 Xianxialing Road,Qingdao,266061,P.R.China
Tel: +86-532-88967320
E-mail: lianzhan at fio.org.cn
<dep.gif>
_______________________________________________
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/20160307/9d3f6419/attachment.htm>

------------------------------

_______________________________________________
MITgcm-support mailing list
MITgcm-support at mitgcm.org
http://mitgcm.org/mailman/listinfo/mitgcm-support


End of MITgcm-support Digest, Vol 153, Issue 10
***********************************************

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


More information about the MITgcm-support mailing list