[MITgcm-support] using RBCS to generate flow

Jean-Michel Campin jmc at ocean.mit.edu
Sun Jan 12 12:11:27 EST 2014


Hi Caroline,

I did not try (yet) to run your set-up, but I noticed in your "code/CPP_OPTIONS.h":
> C o Include/exclude phi_hyd calculation code
> C-- CK - not necessary?
> C   #define INCLUDE_PHIHYD_CALCULATION_CODE
> #undef INCLUDE_PHIHYD_CALCULATION_CODE
This can certainly explain why no current develop when just applying
 T,S forcing,

Now, I don't have the impression that your older version of MITgcm code
should behave much differently with this CPP option left #undef
(option INCLUDE_PHIHYD_CALCULATION_CODE is old and has not been changed
recently, if I remember well).

Could you re-run your test with "#define INCLUDE_PHIHYD_CALCULATION_CODE"
in code/CPP_OPTIONS.h ?
(in fact, I think that the defaut CPP_OPTIONS.h from model/inc should
 work fine for this set-up).

Cheers,
Jean-Michel
 
On Tue, Jan 07, 2014 at 09:54:35AM -0500, Jean-Michel Campin wrote:
> Hi Caroline,
> 
> On Tue, Jan 07, 2014 at 03:06:56PM +0100, katsman wrote:
> > before I send you  a pile of files you don't want: the binary input
> > files, the data.* files, and the input files for the compilation?
> 
> Yes, this is what I meant, corresponding to this case you mentionned:
> >>>A test that really makes me think there is a bug in the rbcs package
> >>>rather than me doing something stupid is that when I only restore T
> >>>with a gradient in x, I expect to see a purely baroclinic V develop
> >>>in geostrophic balance with that. In stead, nothing happens (I can
> >>>run it for a month, no flow develops at all).
> 
> Can you put everything in a tar file (gzip), and send it to me
> (not to the support list since there is some size limitation there).
> 
> Cheers,
> Jean-Michel
> 
> > On 01/07/2014 02:44 PM, mitgcm-support-request at mitgcm.org wrote:
> > >Send MITgcm-support mailing list submissions to
> > >	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. Re: using RBCS to generate flow (Jean-Michel Campin)
> > >    2. Re: error with exf forcing 'variable not	in	namelist (???)
> > >
> > >
> > >----------------------------------------------------------------------
> > >
> > >Message: 1
> > >Date: Mon, 6 Jan 2014 21:25:34 -0500
> > >From: Jean-Michel Campin <jmc at ocean.mit.edu>
> > >To: mitgcm-support at mitgcm.org
> > >Subject: Re: [MITgcm-support] using RBCS to generate flow
> > >Message-ID: <20140107022534.GC16337 at ocean.mit.edu>
> > >Content-Type: text/plain; charset=us-ascii
> > >
> > >Hi Caroline,
> > >
> > >I took a look at your parameter files, but did not find anything
> > >strange.
> > >
> > >May be you could send the exact set-up (and indicate the version of the
> > >MITgcm code you are using) that corresponds to this:
> > >>>A test that really makes me think there is a bug in the rbcs package
> > >>>rather than me doing something stupid is that when I only restore T
> > >>>with a gradient in x, I expect to see a purely baroclinic V develop
> > >>>in geostrophic balance with that. In stead, nothing happens (I can
> > >>>run it for a month, no flow develops at all).
> > >This looks simple enough, and will try to reproduce the problem.
> > >
> > >Cheers,
> > >Jean-Michel
> > >
> > >On Mon, Jan 06, 2014 at 03:55:36PM +0100, katsman wrote:
> > >>Dear Jean-Michel,
> > >>
> > >>The files are attached.
> > >>
> > >>Caroline
> > >>
> > >>
> > >>
> > >>
> > >>On 12/24/2013 06:00 PM, mitgcm-support-request at mitgcm.org wrote:
> > >>>Send MITgcm-support mailing list submissions to
> > >>>	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. Re: using RBCS to generate flow (Jean-Michel Campin)
> > >>>
> > >>>
> > >>>----------------------------------------------------------------------
> > >>>
> > >>>Message: 1
> > >>>Date: Tue, 24 Dec 2013 09:26:52 -0500
> > >>>From: Jean-Michel Campin <jmc at ocean.mit.edu>
> > >>>To: mitgcm-support at mitgcm.org
> > >>>Subject: Re: [MITgcm-support] using RBCS to generate flow
> > >>>Message-ID: <20131224142652.GB19034 at ocean.mit.edu>
> > >>>Content-Type: text/plain; charset=us-ascii
> > >>>
> > >>>Hi Caroline,
> > >>>
> > >>>Could you send few parameter files that you are using when trying to
> > >>>work with checkpoint64 code ?
> > >>>it would be "data", "data.pkg" and "data.rbcs".
> > >>>
> > >>>Cheers,
> > >>>Jean-Michel
> > >>>
> > >>>On Tue, Dec 24, 2013 at 01:54:37PM +0100, katsman wrote:
> > >>>>Dear MITgcm developers,
> > >>>>
> > >>>>Over the past years, I used the RBCS package to generate a flow in
> > >>>>an (otherwise unforced) basin representing the Labrador Sea, by
> > >>>>restoring the flow to a prescibed 3D-temperature and velocity field
> > >>>>in a corner of the basin (T and velocity in geostrophic balance).
> > >>>>This worked excellent in a (admittedly old) checkpoint58-version in
> > >>>>which we manually added a restoring term on U and V analogous to the
> > >>>>programmed T, S part.
> > >>>>
> > >>>>When I got a new workstation I thought it time to upgrade to the
> > >>>>most recent MITgcm version, but I cannot get the package to work in
> > >>>>the same way (and I tried many things over the past months, so I am
> > >>>>getting a bit desperate...).
> > >>>>
> > >>>>The new checkpoint64 is supposed to be able to restore T,U and V,
> > >>>>but I find that - when I prescribe my T,V fields again as before -
> > >>>>in the sponge region defined by the mask, T is restored fine, while
> > >>>>V is restored fine only during the first few timesteps of the
> > >>>>simulation. Then a purely baroclinic U develops as well, while V
> > >>>>becomes barotropic (despite RBCS acting on it). Intriguing, but not
> > >>>>what I wanted.
> > >>>>
> > >>>>A test that really makes me think there is a bug in the rbcs package
> > >>>>rather than me doing something stupid is that when I only restore T
> > >>>>with a gradient in x, I expect to see a purely baroclinic V develop
> > >>>>in geostrophic balance with that. In stead, nothing happens (I can
> > >>>>run it for a month, no flow develops at all).
> > >>>>
> > >>>>One of the earlier versions (c62) has yet another version of the
> > >>>>RBCS package. When I do a test with T-restore only (U,V is not
> > >>>>standard in that one), a baroclinic flow does develop obeying
> > >>>>geostrophy.
> > >>>>
> > >>>>Any ideas what is wrong here? I checked - the  model does frequent
> > >>>>the appropriate lines of code  in rbcs_add_tendency in the c64
> > >>>>version  to change the gV parameter - I suspect somewhere in the
> > >>>>code U and V are mixed up. Notably, the baroclinic flow that
> > >>>>develops in the sponge region is roughly the same strength as the V
> > >>>>I prescribe
> > >>>>
> > >>>>Any ideas?? (if the description is unclear I can send pictures)
> > >>>>
> > >>>>Thanks in advance & happy holidays
> > >>>>Caroline
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>_______________________________________________
> > >>>>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
> > >>>
> > >>>
> > >>>End of MITgcm-support Digest, Vol 126, Issue 44
> > >>>***********************************************
> > >>#; ====================
> > >># | Model parameters |
> > >># ====================
> > >>#
> > >># Continuous equation parameters
> > >>  &PARM01
> > >># tRef= 5.367, 4.102, 3.628, 3.447, 3.341,
> > >>#       3.270, 3.197, 3.156, 3.133, 3.115,
> > >>#       3.096, 3.050, 2.947, 2.781, 2.655,
> > >># sRef= 15*0.0,
> > >># normal
> > >>  tRef = 5.36700,4.10200,3.62800,3.44700,3.34100,
> > >>         3.27710,3.21525,3.17308,3.14642,3.12914,
> > >>         3.11629,3.10382,3.08450,3.05690,3.00880,
> > >>         2.95112,2.87507,2.79207,2.72171,2.63647,
> > >># thick upper layer  - changed  T2+T3
> > >># tRef = 5.36700,3.92425,3.60538,3.44700,3.34100,
> > >>#        3.27710,3.21525,3.17308,3.14642,3.12914,
> > >>#        3.11629,3.10382,3.08450,3.05690,3.00880,
> > >>#        2.95112,2.87507,2.79207,2.72171,2.63647,
> > >>  sRef= 20*35.0,
> > >>  viscAz=1.E-5,
> > >># viscAh=40.,
> > >>  viscA4=1.5e09,
> > >>  no_slip_sides=.TRUE.,
> > >>  no_slip_bottom=.TRUE.,
> > >># diffKhT=20.,
> > >>  diffK4T=0.75e09,
> > >>  diffKzT=1.0e-05,
> > >>  diffKhS=0.0,
> > >>  diffKzS=0.0,
> > >>  f0=1.16e-4,
> > >>  beta=1.4e-11,
> > >>  tAlpha=1.7e-4,
> > >>  sBeta =0.0,
> > >>#gravity=9.81,
> > >>  rigidLid=.FALSE.,
> > >>  implicitFreeSurface=.TRUE.,
> > >>#useCDscheme=.TRUE.,
> > >>#useNHMTerms=.TRUE.,
> > >>  eosType='LINEAR',
> > >>  rhoNil=1028.,
> > >>  hFacMin=0.05,
> > >>  hFacMinDz=50,
> > >>#nonHydrostatic=.TRUE.,
> > >>  readBinaryPrec=64,
> > >>  bottomDragLinear=0.E-4,
> > >>  exactConserv=.TRUE.,
> > >>  &
> > >>
> > >># Elliptic solver parameters
> > >>  &PARM02
> > >>  cg2dMaxIters=300,
> > >>  cg2dTargetResidual=1.E-13,
> > >>  cg3dMaxIters=20,
> > >>  cg3dTargetResidual=1.E-8,
> > >>  &
> > >>
> > >># Time stepping parameters
> > >>  &PARM03
> > >>  startTime=0,
> > >># 24 hrs
> > >>  endTime=86400,
> > >># 3 days
> > >># endTime=259200,
> > >>  deltaT=600,
> > >>  deltaTtracer=600,
> > >>#deltaTClock =86400.0,
> > >>  abEps=0.01,
> > >># pChkptFreq=000,
> > >>  chkptFreq=2592000,
> > >># 1 day
> > >>  dumpFreq=600,
> > >># 3 day
> > >>#  dumpFreq=259200,
> > >># dumpFreq=3600,
> > >>  cadjFreq=600,
> > >>  monitorFreq=1.,
> > >>  periodicExternalForcing=.FALSE.,
> > >># periodicExternalForcing=.TRUE.,
> > >># 1 / 12 months
> > >># externForcingPeriod=2592000.,
> > >># externForcingCycle=31104000.,
> > >>  &
> > >># Gridding parameters
> > >>  &PARM04
> > >>  usingCartesianGrid=.TRUE.,
> > >># delZ= 100, 100, 100, 100, 100,
> > >>#       150, 150, 150, 150, 200,
> > >>#       225, 275, 350, 400, 450,
> > >>#
> > >>#       # normal
> > >>  delZ= 100,100,100,100,100,
> > >>        125,125,125,125,125,
> > >>        125,150,150,150,175,
> > >>        175,175,200,250,325,
> > >># thick upper layer
> > >># delZ= 150,75,75,100,100,
> > >>#       125,125,125,125,125,
> > >>#       125,150,150,150,175,
> > >>#       175,175,200,250,325,
> > >>  delX=162*7.5e03,
> > >>  delY=210*7.5e03,
> > >>  &
> > >># Input datasets
> > >>  &PARM05
> > >># bathyFile = '../INPUT_OCT/topogLS_rbcs_narrow_dijk_steep_7500_64.bin',
> > >>  bathyFile = '../INPUT_OCT/topogLS_rbcs_narrow_dijk_steep_7500_64.bin',
> > >># surfQfile = '../INPUT_OCT/Qfile_100_7.5km.bin',
> > >>#
> > >># bathyFile = '../INPUT_IDL/topogLS_rbcs_09_dijk_64.bin',
> > >># surfQfile = '../INPUT_IDL/Qfile_107_7.5km_64.bin',
> > >>  &
> > >>
> > >># RBCS package parameters:
> > >>  &RBCS_PARM01
> > >>#------------------------------------------------------------------------------
> > >># switches
> > >>#------------------------------------------------------------------------------
> > >>    useRBCtemp=.TRUE.,
> > >>    useRBCvVel=.TRUE.,
> > >>    useRBCuVel=.TRUE.,
> > >>#   useRBCsalt=.TRUE.,
> > >>#------------------------------------------------------------------------------
> > >>#- relaxation times
> > >>#------------------------------------------------------------------------------
> > >>     tauRelaxU=600.,
> > >>     tauRelaxV=600.,
> > >>     tauRelaxT=600.,
> > >>#------------------------------------------------------------------------------
> > >># masks - #1 and #2 = T,S , #3 = tracers ;
> > >># masks  U,V have explicit name - if left out then TMask = used
> > >>#------------------------------------------------------------------------------
> > >># -----OCTAVE VERSION----------------------------
> > >>    relaxMaskFile='../INPUT_OCT/TempMask_7500_north_64_z20.bin','../INPUT_OCT/SaltMask_7500_north_64_z20.bin',
> > >>    relaxMaskUFile='../INPUT_OCT/UvelMask_7500_north_64_z20.bin',
> > >>    relaxMaskVFile='../INPUT_OCT/VvelMask_7500_northeast_64_z20.bin',
> > >>#
> > >># -----IDL VERSION
> > >>#   relaxMaskFile='../INPUT_IDL/TempMask_75_east_64_z20.bin','../INPUT_IDL/SaltMask_75_east_64_z20.bin',
> > >>#   relaxMaskVFile='../INPUT_IDL/VMask_75_east_64_z20.bin',
> > >>#------------------------------------------------------------------------------
> > >># files containing relaxation flds  have explicit name
> > >>#------------------------------------------------------------------------------
> > >># -----OCTAVE VERSION
> > >>    relaxTFile='../INPUT_OCT/TempFile_7500_drho26_seas055_north_64_z20.bin',
> > >>    relaxUFile='../INPUT_OCT/UvelFile_7500_drho26_seas055_north_64_z20.bin',
> > >>    relaxVFile='../INPUT_OCT/VvelFile_7500_drho26_seas055_north_64_z20.bin',
> > >>#   relaxTFile='../INPUT_OCT/TempFile_7500_drho26_fix_northeast_64_z20.bin',
> > >>#   relaxVFile='../INPUT_OCT/VvelFile_7500_drho26_fix_northeast_64_z20.bin',
> > >># -----IDL VERSION
> > >>#   relaxTFile='../INPUT_IDL/TempFile_75_drho26_seas100_east_64_z20.bin',
> > >>#   relaxVFile='../INPUT_IDL/VFile_75_drho26_seas100_east_64_z20.bin',
> > >>#------------------------------------------------------------------------------
> > >>    rbcsIniter=0,
> > >># 1 / 12 months
> > >>#   rbcsForcingPeriod=2592000.,
> > >>#   rbcsForcingCycle=31104000.,
> > >># 5 / 60 days
> > >>    rbcsForcingPeriod=432000.,
> > >>    rbcsForcingCycle=5184000.,
> > >>  &
> > >>
> > >
> > >>_______________________________________________
> > >>MITgcm-support mailing list
> > >>MITgcm-support at mitgcm.org
> > >>http://mitgcm.org/mailman/listinfo/mitgcm-support
> > >
> > >
> > >
> > >------------------------------
> > >
> > >Message: 2
> > >Date: Tue, 7 Jan 2014 21:44:16 +0800 (CST)
> > >From: ??? <oceanlizy at 163.com>
> > >To: mitgcm-support at mitgcm.org
> > >Subject: Re: [MITgcm-support] error with exf forcing 'variable not	in
> > >	namelist
> > >Message-ID: <7d11e811.11c7a.1436cf25171.Coremail.oceanlizy at 163.com>
> > >Content-Type: text/plain; charset="gbk"
> > >
> > >Thank you for your quick reply,Martin !
> > >I did as you told ,but the error is still there .
> > >I set up a model to simulate wind-driven circulation in a semi-enclosed gulf . The external force is wind .I want to run the model with wind forcing for 1 years .  I download 12 monthly-averaged wind speed datas ,and made the uwindfile='u2007.bin' in format of "nx*ny*12" ,as well as vwindfile 'v2007'.  As to OBCS, I deal it the same as wind datas, namely,all the obcs files are nx/ny *nz *12 format .
> > >below are my data,data.exf and data.obcs files:
> > >data :
> > ># ====================
> > ># | Model parameters |
> > ># ====================
> > >#
> > ># Continuous equation parameters
> > >  &PARM01
> > ># tRef= 26.5, 25.5, 24.4, 23.1, 21.9,
> > >#       20.5, 18.7, 16.4, 13.6, 11.3,
> > >#        8.9,  6.5,  4.6,  4.6,  4.6,
> > >#       4.6,  4.6,  4.6,  4.6,  4.6,
> > >#      4.6,  4.6,  4.6,  4.6,  4.6,
> > >#        4.6,  4.6,  4.6,  4.6,  4.6,
> > >#        4.6,  4.6,  4.6,  4.6,  4.6,
> > >#        4.6,
> > ># sRef= 33.28, 33.59, 33.87, 34.13, 34.36,
> > >#       34.53, 34.61, 34.64, 34.56, 34.48,
> > >#       34.39, 34.35, 34.38, 34.38, 34.38,
> > >#       34.38, 34.38, 34.38, 34.38, 34.38,
> > >#       34.38, 34.38, 34.38, 34.38, 34.38,
> > >#       34.38, 34.38, 34.38, 34.38, 34.38,
> > >#       34.38, 34.38, 34.38, 34.38, 34.38,
> > >#       34.38,
> > >  viscAz=1.0E-4,
> > >  viscAh=4.E+2,
> > >  no_slip_sides=.FALSE.,
> > >  no_slip_bottom=.TRUE.,
> > >  diffKhT=4.E2,
> > >  diffKzT=3.E-5,
> > >  diffKhS=4.E2,
> > >  diffKzS=3.E-5,
> > >  tAlpha=2.E-4,
> > >  sBeta=0.,
> > >  gravity=9.81,
> > >  bottomDragLinear=1.E-6,
> > >  bottomDragQuadratic=1.E-5,
> > >  hFacMin=0.1,
> > >  rigidLid=.FALSE.,
> > >  implicitFreeSurface=.TRUE.,
> > >  staggerTimestep=.FALSE.,
> > >  eosType='LINEAR',
> > >  readBinaryPrec=64,
> > >  implicitdiffusion=.TRUE.,
> > >  implicitviscosity=.TRUE.,
> > ># useCoriolis=.TRUE.,
> > >  &
> > >
> > >
> > ># Elliptic solver parameters
> > >  &PARM02
> > >  cg2dMaxIters=500,
> > >  cg2dTargetResidual=1.E-10,
> > >  &
> > >
> > >
> > ># Time stepping parameters
> > >  &PARM03
> > >  startTime=0.,
> > >  endTime=31104000,
> > >  nIter0=0,
> > >  deltaT=100.0,
> > ># tauCD=321428.,
> > ># deltaTtracer=108000.0,
> > ># deltaTClock =108000.0,
> > ># cAdjFreq=-1.,
> > >   abEps=0.1,
> > ># pChkptFreq=1296000.,
> > ># chkptFreq=1296000.0,
> > >   dumpFreq=86400.0,
> > ># taveFreq=1296000.,
> > ># tauThetaClimRelax=43200.0,
> > ># tauSaltClimRelax=1296000.0,
> > >   monitorFreq=36000.,
> > >  &
> > >
> > >
> > ># Gridding parameters
> > >  &PARM04
> > >  usingCartesianGrid=.FALSE.,
> > >  usingSphericalPolarGrid=.TRUE.,
> > >  delZ=  2,3,5,5,5,5,
> > >         5,5,5,5,5,5,
> > >         5,5,5,7,8,10,
> > >         15,20,25,30,40,50,
> > >         60,100,150,200,250,300,
> > >         400,500,500,500,500,500,
> > >
> > >
> > >  ygOrigin=24.5,
> > >  xgOrigin=117.525,
> > >  delX=134*0.1,
> > >  delY=165*0.1,
> > >  &
> > >
> > >
> > ># Input datasets
> > >  &PARM05
> > >  hydrogThetaFile='initemp_66400.bin',
> > >  hydrogSaltFile='inisalt_66400.bin',
> > >  bathyFile='topog.bin',
> > >  &
> > >data.exf :
> > ># External Forcing Data
> > ># *********************
> > >  &EXF_NML_01
> > >  exf_iprec         = 64,
> > >  useExfCheckRange=.TRUE.,
> > >  &
> > ># *******************
> > >  &EXF_NML_02
> > >#
> > >  uwindstartdate1=20070101,
> > >  uwindstartdate2=000000,
> > >  uwindperiod=2592000.0,
> > >#
> > >  vwindstartdate1=20070101,
> > >  vwindstartdate2=000000,
> > >  vwindperiod=2592000.0,
> > >#
> > >  uwindfile  = 'u2007.bin',
> > >  vwindfile   =  'v2007.bin ',
> > >  &
> > >
> > >
> > ># ***************
> > >  &EXF_NML_03
> > >  uwind_lon0    = 117.575,
> > >  uwind_lon_inc = 0.1,
> > >  uwind_lat0    = 24.55,
> > >  uwind_lat_inc = 165*0.1,
> > >  uwind_nlon    = 134,
> > >  uwind_nlat    = 165,
> > >  vwind_lon0    = 117.575,
> > >  vwind_lon_inc = 0.1,
> > >  vwind_lat0    = 24.55,
> > >  vwind_lat_inc = 165*0.1,
> > >  vwind_nlon    = 134,
> > >  vwind_nlat    = 165,
> > >  &
> > >#
> > >  &EXF_NML_OBCS
> > >  obcsNstartdate1=20070101,
> > >  obcsNstartdate2=0000000,
> > >  obcsNperiod=2592000,
> > >#
> > >  obcsEstartdate1=20070101,
> > >  obcsEstartdate2=0000000,
> > >  obcsEperiod=2592000,
> > >#
> > >  obcsSstartdate1=20070101,
> > >  obcsSstartdate2=0000000,
> > >  obcsSperiod=2592000,
> > >  &
> > >data.obcs:
> > ># Open boundaries
> > ># ***************
> > >  &OBCS_PARM01
> > >  OB_Jsouth=134*1,
> > >  OB_Ieast=165*134,
> > >  OB_Jnorth=134*165,
> > >  useOBCSprescribe=.TRUE.,
> > >#
> > >  OBSsFile='obcs_southsalt.bin',
> > >  OBStFile='obcs_southtemp.bin',
> > >  OBSuFile='obcs_southu.bin',
> > >  OBSvFile='obcs_southv.bin',
> > >  OBEsFile='obcs_eastsalt.bin',
> > >  OBEtFile='obcs_easttemp.bin',
> > >  OBEuFile='obcs_eastu.bin',
> > >  OBEvFile='obcs_eastv.bin',
> > >  OBNsFile='obcs_northsalt.bin',
> > >  OBNtFile='obcs_northtemp.bin',
> > >  OBNvFile='obcs_northv.bin',
> > >  OBNuFile='obcs_northu.bin',
> > >  &
> > >
> > >
> > >I think I have nothing wrong with my data.exf and data.obcs file ,but it still occured such an error ..
> > >I doubt that when using exf,obcs package , there must be a " EXF_OPTIONS.h" and "OBCS_OPTIONS.h" file in code ?  and  if I use wind speed as the external force input , how should I modify the code in " EXF_OPTIONS.h" ?
> > >
> > >
> > >thank you again ,Martin !
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >At 2014-01-07 01:00:02,mitgcm-support-request at mitgcm.org wrote:
> > >>Send MITgcm-support mailing list submissions to
> > >>	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. Re: error with exf forcing 'variable not in	namelist '
> > >>      (Martin Losch)
> > >>   2. Re: format of input files wrong in regional model with open
> > >>      boundary conditions? (Jonny Williams)
> > >>   3. Re: MITgcm-support Digest, Vol 126, Issue 44 (katsman)
> > >>
> > >>
> > >>----------------------------------------------------------------------
> > >>
> > >>Message: 1
> > >>Date: Mon, 6 Jan 2014 10:04:25 +0100
> > >>From: Martin Losch <Martin.Losch at awi.de>
> > >>To: MITgcm Support <mitgcm-support at mitgcm.org>
> > >>Subject: Re: [MITgcm-support] error with exf forcing 'variable not in
> > >>	namelist '
> > >>Message-ID: <15CF1A3F-814C-4992-AE56-F80E62FD9277 at awi.de>
> > >>Content-Type: text/plain; charset="utf-8"
> > >>
> > >>Hi there,
> > >>
> > >>did you get a reply? If not:
> > >>
> > >>the error message comes from your compiler and means that something wrong in your namelist EXF_NML_03.
> > >>I would do this:
> > >>1. as a general rule add ?,? after each entry, some compilers tolerate omitting the comma, others don?t.
> > >>2. vstress_lat_inc is a 1-D field, but vstress_lon_inc isn?t (I agree that this is confusing, but exf does not support variable grid spacing in lon-direction for the input fields that are then interpolated to the model grid), so you need to have vstress_lon_inc = 0.1,
> > >>3. remove the blank line in the namelist. That shouldn?t really matter, but who knows ?
> > >>
> > >>So in summary, try this for your EXF_NML_03:
> > >>&EXF_NML_03
> > >>vstress_lon0    = 117.575,
> > >>vstress_lon_inc = 0.1,
> > >>vstress_lat0    = 24.55,
> > >>vstress_lat_inc = 165*0.1,
> > >>vstress_nlon    = 134,
> > >>vstress_nlat    = 165,
> > >>&
> > >>
> > >>Martin
> > >>
> > >>
> > >>On Dec 25, 2013, at 10:17 AM, ??? <oceanlizy at 163.com> wrote:
> > >>
> > >>>Hi ,there;
> > >>>      when I use exf package in my model ,it occured such errors:
> > >>>
> > >>>(PID.TID 0000.0001) EXF_READPARMS: opening data.exf
> > >>>(PID.TID 0000.0001)  OPEN_COPY_DATA_FILE: opening file data.exf
> > >>>(PID.TID 0000.0001) // =======================================================
> > >>>(PID.TID 0000.0001) // Parameter file "data.exf"
> > >>>(PID.TID 0000.0001) // =======================================================
> > >>>(PID.TID 0000.0001) >#
> > >>>(PID.TID 0000.0001) ># *********************
> > >>>(PID.TID 0000.0001) ># External Forcing Data
> > >>>(PID.TID 0000.0001) ># *********************
> > >>>(PID.TID 0000.0001) > &EXF_NML_01
> > >>>(PID.TID 0000.0001) >
> > >>>(PID.TID 0000.0001) > exf_iprec         = 64,
> > >>>(PID.TID 0000.0001) > useExfCheckRange=.TRUE.,
> > >>>(PID.TID 0000.0001) > &
> > >>>(PID.TID 0000.0001) ># *******************
> > >>>(PID.TID 0000.0001) > &EXF_NML_02
> > >>>(PID.TID 0000.0001) >
> > >>>(PID.TID 0000.0001) > vstressstartdate1=20000101,
> > >>>(PID.TID 0000.0001) > vstressstartdate2=000000,
> > >>>(PID.TID 0000.0001) > vstressperiod=2592000.0,
> > >>>(PID.TID 0000.0001) >
> > >>>(PID.TID 0000.0001) > vstressfile  = 'tauy.bin',
> > >>>(PID.TID 0000.0001) >
> > >>>(PID.TID 0000.0001) > &
> > >>>(PID.TID 0000.0001) >
> > >>>(PID.TID 0000.0001) ># ***************
> > >>>(PID.TID 0000.0001) > &EXF_NML_03
> > >>>(PID.TID 0000.0001) >
> > >>>(PID.TID 0000.0001) > vstress_lon0    = 117.575
> > >>>(PID.TID 0000.0001) > vstress_lon_inc = 134*0.1
> > >>>(PID.TID 0000.0001) > vstress_lat0    = 24.55
> > >>>(PID.TID 0000.0001) > vstress_lat_inc = 165*0.1
> > >>>(PID.TID 0000.0001) > vstress_nlon    = 134
> > >>>(PID.TID 0000.0001) > vstress_nlat    = 165
> > >>>(PID.TID 0000.0001) > &
> > >>>(PID.TID 0000.0001)
> > >>>(PID.TID 0000.0001) EXF_READPARMS: reading EXF_NML_01
> > >>>(PID.TID 0000.0001) EXF_READPARMS: reading EXF_NML_02
> > >>>(PID.TID 0000.0001) EXF_READPARMS: reading EXF_NML_03
> > >>>namelist read: variable not in namelist
> > >>>apparent state: unit 11 named /tmp/tmp.Fl81Aot
> > >>>last format: list io
> > >>>lately reading sequential formatted external IO
> > >>>Aborted
> > >>
> > >>
> > >>
> > >>------------------------------
> > >>
> > >>Message: 2
> > >>Date: Mon, 6 Jan 2014 12:15:18 +0000
> > >>From: Jonny Williams <Jonny.Williams at bristol.ac.uk>
> > >>To: MITgcm Support <mitgcm-support at mitgcm.org>
> > >>Subject: Re: [MITgcm-support] format of input files wrong in regional
> > >>	model with open boundary conditions?
> > >>Message-ID:
> > >>	<CAA-NaP5six3kA3AH-1PnXLGLCix5udjQ4vVRH65NGAxoc1beHA at mail.gmail.com>
> > >>Content-Type: text/plain; charset="iso-8859-1"
> > >>
> > >>Hi there and happy new year!
> > >>
> > >>Thank you very much for this. I will give this a go ASAP!
> > >>
> > >>All the best
> > >>
> > >>Jonny
> > >>
> > >>
> > >>On 19 December 2013 16:35, Menemenlis, Dimitris (3248) <
> > >>Dimitris.Menemenlis at jpl.nasa.gov> wrote:
> > >>
> > >>>  Put a wall, i.e., bathymetry =0, at:
> > >>>(i) the north or south boundary and
> > >>>(ii) the east or west boundary.
> > >>>This works because domain is doubly-periodic so a wall
> > >>>at southern end is equivalent to a wall at northern end.
> > >>>
> > >>>   On Dec 19, 2013, at 8:25 AM, Jonny Williams wrote:
> > >>>
> > >>>  Currently I have not specified northern and southern BCs in the model! I
> > >>>assumed that this was taken care of by the external forcing files... Is it
> > >>>possible to let me know how roughly how I would go about this please?
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>_______________________________________________
> > >>>MITgcm-support mailing list
> > >>>MITgcm-support at mitgcm.org
> > >>>http://mitgcm.org/mailman/listinfo/mitgcm-support
> > >>>
> > >>>
> > >>
> > >>-- 
> > >>Dr Jonny Williams
> > >>School of Geographical Sciences
> > >>University of Bristol
> > >>University Road
> > >>BS8 1SS
> > >>
> > >>+44 (0)117 3318352
> > >>jonny.williams at bristol.ac.uk
> > >>bit.ly/jonnywilliams
> > >>-------------- next part --------------
> > >>An HTML attachment was scrubbed...
> > >>URL: <http://mitgcm.org/pipermail/mitgcm-support/attachments/20140106/5c28bd48/attachment.html>
> > >>
> > >>------------------------------
> > >>
> > >>Message: 3
> > >>Date: Mon, 6 Jan 2014 15:55:36 +0100
> > >>From: katsman <katsman at knmi.nl>
> > >>To: <mitgcm-support at mitgcm.org>
> > >>Subject: Re: [MITgcm-support] MITgcm-support Digest, Vol 126, Issue 44
> > >>Message-ID: <52CAC3E8.1020107 at knmi.nl>
> > >>Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
> > >>
> > >>Dear Jean-Michel,
> > >>
> > >>The files are attached.
> > >>
> > >>Caroline
> > >>
> > >>
> > >>
> > >>
> > >>On 12/24/2013 06:00 PM, mitgcm-support-request at mitgcm.org wrote:
> > >>>Send MITgcm-support mailing list submissions to
> > >>>	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. Re: using RBCS to generate flow (Jean-Michel Campin)
> > >>>
> > >>>
> > >>>----------------------------------------------------------------------
> > >>>
> > >>>Message: 1
> > >>>Date: Tue, 24 Dec 2013 09:26:52 -0500
> > >>>From: Jean-Michel Campin <jmc at ocean.mit.edu>
> > >>>To: mitgcm-support at mitgcm.org
> > >>>Subject: Re: [MITgcm-support] using RBCS to generate flow
> > >>>Message-ID: <20131224142652.GB19034 at ocean.mit.edu>
> > >>>Content-Type: text/plain; charset=us-ascii
> > >>>
> > >>>Hi Caroline,
> > >>>
> > >>>Could you send few parameter files that you are using when trying to
> > >>>work with checkpoint64 code ?
> > >>>it would be "data", "data.pkg" and "data.rbcs".
> > >>>
> > >>>Cheers,
> > >>>Jean-Michel
> > >>>
> > >>>On Tue, Dec 24, 2013 at 01:54:37PM +0100, katsman wrote:
> > >>>>Dear MITgcm developers,
> > >>>>
> > >>>>Over the past years, I used the RBCS package to generate a flow in
> > >>>>an (otherwise unforced) basin representing the Labrador Sea, by
> > >>>>restoring the flow to a prescibed 3D-temperature and velocity field
> > >>>>in a corner of the basin (T and velocity in geostrophic balance).
> > >>>>This worked excellent in a (admittedly old) checkpoint58-version in
> > >>>>which we manually added a restoring term on U and V analogous to the
> > >>>>programmed T, S part.
> > >>>>
> > >>>>When I got a new workstation I thought it time to upgrade to the
> > >>>>most recent MITgcm version, but I cannot get the package to work in
> > >>>>the same way (and I tried many things over the past months, so I am
> > >>>>getting a bit desperate...).
> > >>>>
> > >>>>The new checkpoint64 is supposed to be able to restore T,U and V,
> > >>>>but I find that - when I prescribe my T,V fields again as before -
> > >>>>in the sponge region defined by the mask, T is restored fine, while
> > >>>>V is restored fine only during the first few timesteps of the
> > >>>>simulation. Then a purely baroclinic U develops as well, while V
> > >>>>becomes barotropic (despite RBCS acting on it). Intriguing, but not
> > >>>>what I wanted.
> > >>>>
> > >>>>A test that really makes me think there is a bug in the rbcs package
> > >>>>rather than me doing something stupid is that when I only restore T
> > >>>>with a gradient in x, I expect to see a purely baroclinic V develop
> > >>>>in geostrophic balance with that. In stead, nothing happens (I can
> > >>>>run it for a month, no flow develops at all).
> > >>>>
> > >>>>One of the earlier versions (c62) has yet another version of the
> > >>>>RBCS package. When I do a test with T-restore only (U,V is not
> > >>>>standard in that one), a baroclinic flow does develop obeying
> > >>>>geostrophy.
> > >>>>
> > >>>>Any ideas what is wrong here? I checked - the  model does frequent
> > >>>>the appropriate lines of code  in rbcs_add_tendency in the c64
> > >>>>version  to change the gV parameter - I suspect somewhere in the
> > >>>>code U and V are mixed up. Notably, the baroclinic flow that
> > >>>>develops in the sponge region is roughly the same strength as the V
> > >>>>I prescribe
> > >>>>
> > >>>>Any ideas?? (if the description is unclear I can send pictures)
> > >>>>
> > >>>>Thanks in advance & happy holidays
> > >>>>Caroline
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>_______________________________________________
> > >>>>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
> > >>>
> > >>>
> > >>>End of MITgcm-support Digest, Vol 126, Issue 44
> > >>>***********************************************
> > >>-------------- next part --------------
> > >>#; ====================
> > >># | Model parameters |
> > >># ====================
> > >>#
> > >># Continuous equation parameters
> > >>&PARM01
> > >># tRef= 5.367, 4.102, 3.628, 3.447, 3.341,
> > >>#       3.270, 3.197, 3.156, 3.133, 3.115,
> > >>#       3.096, 3.050, 2.947, 2.781, 2.655,
> > >># sRef= 15*0.0,
> > >># normal
> > >>tRef = 5.36700,4.10200,3.62800,3.44700,3.34100,
> > >>        3.27710,3.21525,3.17308,3.14642,3.12914,
> > >>        3.11629,3.10382,3.08450,3.05690,3.00880,
> > >>        2.95112,2.87507,2.79207,2.72171,2.63647,
> > >># thick upper layer  - changed  T2+T3
> > >># tRef = 5.36700,3.92425,3.60538,3.44700,3.34100,
> > >>#        3.27710,3.21525,3.17308,3.14642,3.12914,
> > >>#        3.11629,3.10382,3.08450,3.05690,3.00880,
> > >>#        2.95112,2.87507,2.79207,2.72171,2.63647,
> > >>sRef= 20*35.0,
> > >>viscAz=1.E-5,
> > >># viscAh=40.,
> > >>viscA4=1.5e09,
> > >>no_slip_sides=.TRUE.,
> > >>no_slip_bottom=.TRUE.,
> > >># diffKhT=20.,
> > >>diffK4T=0.75e09,
> > >>diffKzT=1.0e-05,
> > >>diffKhS=0.0,
> > >>diffKzS=0.0,
> > >>f0=1.16e-4,
> > >>beta=1.4e-11,
> > >>tAlpha=1.7e-4,
> > >>sBeta =0.0,
> > >>#gravity=9.81,
> > >>rigidLid=.FALSE.,
> > >>implicitFreeSurface=.TRUE.,
> > >>#useCDscheme=.TRUE.,
> > >>#useNHMTerms=.TRUE.,
> > >>eosType='LINEAR',
> > >>rhoNil=1028.,
> > >>hFacMin=0.05,
> > >>hFacMinDz=50,
> > >>#nonHydrostatic=.TRUE.,
> > >>readBinaryPrec=64,
> > >>bottomDragLinear=0.E-4,
> > >>exactConserv=.TRUE.,
> > >>&
> > >>
> > >># Elliptic solver parameters
> > >>&PARM02
> > >>cg2dMaxIters=300,
> > >>cg2dTargetResidual=1.E-13,
> > >>cg3dMaxIters=20,
> > >>cg3dTargetResidual=1.E-8,
> > >>&
> > >>
> > >># Time stepping parameters
> > >>&PARM03
> > >>startTime=0,
> > >># 24 hrs
> > >>endTime=86400,
> > >># 3 days
> > >># endTime=259200,
> > >>deltaT=600,
> > >>deltaTtracer=600,
> > >>#deltaTClock =86400.0,
> > >>abEps=0.01,
> > >># pChkptFreq=000,
> > >>chkptFreq=2592000,
> > >># 1 day
> > >>dumpFreq=600,
> > >># 3 day
> > >>#  dumpFreq=259200,
> > >># dumpFreq=3600,
> > >>cadjFreq=600,
> > >>monitorFreq=1.,
> > >>periodicExternalForcing=.FALSE.,
> > >># periodicExternalForcing=.TRUE.,
> > >># 1 / 12 months
> > >># externForcingPeriod=2592000.,
> > >># externForcingCycle=31104000.,
> > >>&
> > >># Gridding parameters
> > >>&PARM04
> > >>usingCartesianGrid=.TRUE.,
> > >># delZ= 100, 100, 100, 100, 100,
> > >>#       150, 150, 150, 150, 200,
> > >>#       225, 275, 350, 400, 450,
> > >>#
> > >>#       # normal
> > >>delZ= 100,100,100,100,100,
> > >>       125,125,125,125,125,
> > >>       125,150,150,150,175,
> > >>       175,175,200,250,325,
> > >># thick upper layer
> > >># delZ= 150,75,75,100,100,
> > >>#       125,125,125,125,125,
> > >>#       125,150,150,150,175,
> > >>#       175,175,200,250,325,
> > >>delX=162*7.5e03,
> > >>delY=210*7.5e03,
> > >>&
> > >># Input datasets
> > >>&PARM05
> > >># bathyFile = '../INPUT_OCT/topogLS_rbcs_narrow_dijk_steep_7500_64.bin',
> > >>bathyFile = '../INPUT_OCT/topogLS_rbcs_narrow_dijk_steep_7500_64.bin',
> > >># surfQfile = '../INPUT_OCT/Qfile_100_7.5km.bin',
> > >>#
> > >># bathyFile = '../INPUT_IDL/topogLS_rbcs_09_dijk_64.bin',
> > >># surfQfile = '../INPUT_IDL/Qfile_107_7.5km_64.bin',
> > >>&
> > >>
> > >>-------------- next part --------------
> > >># RBCS package parameters:
> > >>&RBCS_PARM01
> > >>#------------------------------------------------------------------------------
> > >># switches
> > >>#------------------------------------------------------------------------------
> > >>   useRBCtemp=.TRUE.,
> > >>   useRBCvVel=.TRUE.,
> > >>   useRBCuVel=.TRUE.,
> > >>#   useRBCsalt=.TRUE.,
> > >>#------------------------------------------------------------------------------
> > >>#- relaxation times
> > >>#------------------------------------------------------------------------------
> > >>    tauRelaxU=600.,
> > >>    tauRelaxV=600.,
> > >>    tauRelaxT=600.,
> > >>#------------------------------------------------------------------------------
> > >># masks - #1 and #2 = T,S , #3 = tracers ;
> > >># masks  U,V have explicit name - if left out then TMask = used
> > >>#------------------------------------------------------------------------------
> > >># -----OCTAVE VERSION----------------------------
> > >>   relaxMaskFile='../INPUT_OCT/TempMask_7500_north_64_z20.bin','../INPUT_OCT/SaltMask_7500_north_64_z20.bin',
> > >>   relaxMaskUFile='../INPUT_OCT/UvelMask_7500_north_64_z20.bin',
> > >>   relaxMaskVFile='../INPUT_OCT/VvelMask_7500_northeast_64_z20.bin',
> > >>#
> > >># -----IDL VERSION
> > >>#   relaxMaskFile='../INPUT_IDL/TempMask_75_east_64_z20.bin','../INPUT_IDL/SaltMask_75_east_64_z20.bin',
> > >>#   relaxMaskVFile='../INPUT_IDL/VMask_75_east_64_z20.bin',
> > >>#------------------------------------------------------------------------------
> > >># files containing relaxation flds  have explicit name
> > >>#------------------------------------------------------------------------------
> > >># -----OCTAVE VERSION
> > >>   relaxTFile='../INPUT_OCT/TempFile_7500_drho26_seas055_north_64_z20.bin',
> > >>   relaxUFile='../INPUT_OCT/UvelFile_7500_drho26_seas055_north_64_z20.bin',
> > >>   relaxVFile='../INPUT_OCT/VvelFile_7500_drho26_seas055_north_64_z20.bin',
> > >>#   relaxTFile='../INPUT_OCT/TempFile_7500_drho26_fix_northeast_64_z20.bin',
> > >>#   relaxVFile='../INPUT_OCT/VvelFile_7500_drho26_fix_northeast_64_z20.bin',
> > >># -----IDL VERSION
> > >>#   relaxTFile='../INPUT_IDL/TempFile_75_drho26_seas100_east_64_z20.bin',
> > >>#   relaxVFile='../INPUT_IDL/VFile_75_drho26_seas100_east_64_z20.bin',
> > >>#------------------------------------------------------------------------------
> > >>   rbcsIniter=0,
> > >># 1 / 12 months
> > >>#   rbcsForcingPeriod=2592000.,
> > >>#   rbcsForcingCycle=31104000.,
> > >># 5 / 60 days
> > >>   rbcsForcingPeriod=432000.,
> > >>   rbcsForcingCycle=5184000.,
> > >>&
> > >>
> > >>-------------- next part --------------
> > >>A non-text attachment was scrubbed...
> > >>Name: data.pkg
> > >>Type: application/vnd.apple.installer+xml
> > >>Size: 57 bytes
> > >>Desc: not available
> > >>URL: <http://mitgcm.org/pipermail/mitgcm-support/attachments/20140106/e47a177d/attachment-0001.pkg>
> > >>
> > >>------------------------------
> > >>
> > >>_______________________________________________
> > >>MITgcm-support mailing list
> > >>MITgcm-support at mitgcm.org
> > >>http://mitgcm.org/mailman/listinfo/mitgcm-support
> > >>
> > >>
> > >>End of MITgcm-support Digest, Vol 127, Issue 6
> > >>**********************************************
> > >-------------- next part --------------
> > >An HTML attachment was scrubbed...
> > >URL: <http://mitgcm.org/pipermail/mitgcm-support/attachments/20140107/c31c5aa7/attachment.htm>
> > >
> > >------------------------------
> > >
> > >_______________________________________________
> > >MITgcm-support mailing list
> > >MITgcm-support at mitgcm.org
> > >http://mitgcm.org/mailman/listinfo/mitgcm-support
> > >
> > >
> > >End of MITgcm-support Digest, Vol 127, Issue 7
> > >**********************************************
> > 
> > 
> > _______________________________________________
> > 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