[MITgcm-support] MITgcm-support Digest, Vol 127, Issue 7

katsman katsman at knmi.nl
Tue Jan 7 09:06:56 EST 2014


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?


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
> **********************************************




More information about the MITgcm-support mailing list