[MITgcm-support] error with exf forcing 'variable not in namelist

李志远 oceanlizy at 163.com
Tue Jan 7 08:44:16 EST 2014


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-0001.htm>


More information about the MITgcm-support mailing list