[MITgcm-support] Re: advective and diffusive diagnostics
Stephanie Dutkiewicz
stephd at ocean.mit.edu
Tue Mar 6 16:01:01 EST 2007
Val -
I'm not sure on the answer to this, but I would be
careful about believing the units given by the diagnostic
pkg for the ptracer advect/diffusive fluxes...the
diagnostic pkg doesn't, for instance, know that your
model ptracers are in mmol/m3 -- not mol/m3 -- or kg/m3 --
or -- ?? --
So I think you will have to work out for yourself what
the units are ... given that these diagnostic will
be done exactly the same way as for salt or theta...
you'll just have to add your ptracer specific units into
the mix.
steph
On Tue, 6 Mar 2007, Valerie Benesh wrote:
> Hi,
>
> Thanks for your help so far on this. I looked at the MITgcm support
> archives, and the link is very helpful when considering theta and salinity.
> The units for both of those tracers make sense to me, as the advective
> fluxes are calculated as a volume transport times the tracers.
>
> I am still having trouble understanding the units of the ptracers: dic
> advective fluxes for example. The units are listed as (kg/kg)*(m^3)/s.
> When I look through the code, it is calculated as volume transport (m^3/s)
> times the tracer, which is kept in (mol/m^3) I believe. Is the tracer kept
> as (kg tracer / kg water) in this case? Otherwise, I don't see how the
> units can work out. Thank you for your help.
>
> -Val
>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Fri, 02 Mar 2007 09:45:19 +0100
>> From: Martin Losch <Martin.Losch at awi.de>
>> Subject: Re: [MITgcm-support] advective and diffusive diagnostics
>> To: mitgcm-support at mitgcm.org
>> Message-ID: <34549106-F834-4211-9D18-33AE07614991 at awi.de>
>> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
>>
>> Hi,
>> let me add a related question:
>>
>> for vertical diffusive flux there are two fields:
>> 1. DFrI_TH, implicit diffusive flux of theta
>> 2. DFrE_TH, explicit diffusive flux of theta
>>
>> when I use a vertical mixing scheme that require implicit vertical
>> diffusion such as KPP (in conjunction with GMredi), I expect that all
>> diffusive flux is in DFrI_TH. But I still get a small contribution in
>> DFrE_TH (explicit diffusive flux). Why is that so?
>>
>> (Actually I have tried this only with passive tracers, so DFrITR01
>> and DFrETR01, but from looking a the code I don't see, why it should
>> be different for theta).
>>
>> Martin
>>
>> On 1 Mar 2007, at 20:29, Patrick Heimbach wrote:
>>
>>>
>>> To add to Baylor's description at the thread
>>> http://forge.csail.mit.edu/pipermail/mitgcm-support/2007-February/
>>> 004605.html
>>>
>>> Quoting:
>>> 1) UVELTH is just the correlation between U and T.
>>> 2) UTHMASS is the correlation between U and T, weighted by 'mass', or
>>> HFac, which gives free-surface corrections.
>>> 3) ADVx_TH is the 'effect of advection'. It includes flux-limiting
>>> and diffusion from the numerical scheme.
>>>
>>> there is a fourth diagnostic
>>> 4) DFxE_TH
>>> which could be termed "diffusive", i.e. it contains all
>>> non-advective components in the dT/dt sum, such as diffusion due to
>>> Laplacian or biharmonic diffusion (diffKh, diffK4) and due to GM/Redi.
>>>
>>> The fields 3) and 4) (ADVx_TH, DFxE_TH) are mass-weighted as well
>>> (yes, it's the mass of water in the grid cell),
>>> so you don't have to worry about cell area, thickness or surface
>>> corrections
>>> when computing sums or budgets.
>>>
>>>
>>> -p.
>>>
>>>
>>>
>>> On Mar 1, 2007, at 1:54 PM, Valerie Benesh wrote:
>>>
>>>> I am currently trying to understand the units of the advective and
>>>> diffusive fluxes in the available diagnostics. What is the
>>>> difference between mass-weighted transport of a tracer and the
>>>> advective flux of the tracer? Does the mass transport include
>>>> diffusion? I take it mass-weighting involves the mass of water in
>>>> the grid cell? How exactly are the units (kg/kg)*(m/s) come by
>>>> for mass-weighted transport? How are the units (kg/kg)*(m^3/s)
>>>> achieved for fluxes of the tracer? Are these the fluxes
>>>> themselves at each cell boundary? Any help understanding these
>>>> units is appreciated. Thanks,
>>>>
>>>> Val
>>>>
>>>>
>>>>
>>>> ***************************************************
>>>> Val Bennington
>>>> Graduate Student
>>>> Atmospheric and Oceanic Sciences
>>>> University of Wisconsin-Madison
>>>> benesh at wisc.edu
>>>> ***************************************************
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> MITgcm-support mailing list
>>>> MITgcm-support at mitgcm.org
>>>> http://mitgcm.org/mailman/listinfo/mitgcm-support
>>>
>>> ---
>>> Dr Patrick Heimbach | heimbach at mit.edu | http://www.mit.edu/~heimbach
>>> MIT | EAPS, 54-1518 | 77 Massachusetts Ave | Cambridge, MA 02139, USA
>>> FON: +1-617-253-5259 | FAX: +1-617-253-4464 | SKYPE: patrick.heimbach
>>>
>>>
>>> _______________________________________________
>>> MITgcm-support mailing list
>>> MITgcm-support at mitgcm.org
>>> http://mitgcm.org/mailman/listinfo/mitgcm-support
>>
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Fri, 02 Mar 2007 10:02:11 +0100
>> From: Martin Losch <Martin.Losch at awi.de>
>> Subject: Re: [MITgcm-support] KPP & OB file
>> To: mitgcm-support at mitgcm.org
>> Message-ID: <D9706EBD-1998-4453-9C02-BE48CFDAD536 at awi.de>
>> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
>>
>> Hi Riema,
>>
>> In order to use KPP you have to put "kpp" into your local
>> packages.conf and you have to set #define SHORTWAVE_HEATING in your
>> local CPP_OPTIONS.h because kpp requires a two band incoming
>> radiation (short wave= visible light and long wave = the remaining
>> part). The model will stop if you don't have short wave heating defined.
>> You don't need to set any other parameters, unless you are unhappy
>> with the choice of default values for, say, Ricr, etc. (see
>> kpp_readparms.F). I have never changed them so far, but it's
>> possible. KPP then compute vertical mixing coefficients etc based on
>> your present vertical stratification, vertical shear, surface fluxes,
>> etc. (see, eg., Large et al 1994 for details)
>>
>> OBCS:
>> exp4 gives an example of how to specify CONSTANT (in time) open
>> boundary values from files:
>> useOBCSprescribe = .TRUE., (enables reading from files in general)
>> OBNuFile = 'OBmeridU.bin', (example of a file)
>> [...]
>> these files were generated with exp4/input/gendata.m. The script tell
>> you that a filed for the northern (southern) boundary should have the
>> dimension (nx,nr) and for eastern (western), (ny,nr).
>>
>> If you want to specify time dependent boundary values you can do that
>> too. For example, you have hourly data you have create a field
>> (nx,nr,nt), where nt is the number of "hours" you have. and then you
>> use the parameters
>> periodicExternalForcing=.TRUE.,
>> externForcingPeriod=3600.,
>> in the file "data", in namelist PARM03. If your data is the same
>> after say 12 hour (ie., that you want to use the fields repeatedly)
>> then add this parameter in data
>> externForcingCycle=43200.,
>> These parameters that control reading external forcing data (also
>> surface forcing if you use any) in general. the drawback is that all
>> forcing data have to be at the exact same time levels. The advantage
>> is , that it's simple.
>> The alternative is to use the exf-package, where you can use
>> different frequencies etc for different input fields, but it's also
>> far more complicated.
>>
>> Does that help?
>>
>> M
>>
>> On 2 Mar 2007, at 02:45, Riema Rachmayani wrote:
>>
>>> thanks martin for KPP...KPP is special in that you have to set
>>> #define SHORTWAVE_HEATING in CPP_OPTIONS.h in addtion...so you
>>> mean that KPP is used ONLY when we define shortwave_heating??so i
>>> dont need to change Ricr for my internal wave case...because i
>>> thought it influence of dynamic stability...
>>>
>>> one more question :
>>>
>>> now i'd like to ask about open boundaries file, as in \verification
>>> \exp4\input\data.obcs :
>>>
>>> # Open-boundaries
>>> &OBCS_PARM01
>>> OB_Jnorth=80*-1,
>>> OB_Jsouth=80*1,
>>> OB_Ieast=42*-1,
>>> OB_Iwest=42*1,
>>> #useOrlanskiNorth=.TRUE.,
>>> #useOrlanskiSouth=.TRUE.,
>>> #useOrlanskiEast=.TRUE.,
>>> #useOrlanskiWest=.FALSE.,
>>> useOBCSprescribe = .TRUE.,
>>> OBNuFile = 'OBmeridU.bin',
>>> OBSuFile = 'OBmeridU.bin',
>>> OBWuFile = 'OBzonalU.bin',
>>> OBEuFile = 'OBzonalU.bin',
>>> OBWsFile = 'OBzonalS.bin',
>>> OBWptrFile(1) = 'OBzonalS.bin',
>>> &
>>> # Orlanski parameters
>>> &OBCS_PARM02
>>> #Cmax=0.45,
>>> #cVelTimeScale=1000.,
>>> &
>>>
>>> in the blue line means that data open boundaries is given from
>>> data observation/prediction?? may i know how to read and to write
>>> (format) for that open bondaries file?? is the data read every time
>>> step or every one hour??how to interpolate them?? in what routines
>>> that files read??
>>>
>>> in my case, i'm gonna use tidal prediction data of eta (elevation)
>>> from ORITIDE from Ocean Research Instute, University of Tokyo, the
>>> data is in every one hour, and usually we use spline cubic
>>> subroutine to interpolated one hour data become every time step
>>> data, so that every time step data/value used for open boundaries
>>> input/value...how to modify my case in MITgcm?? because as far i
>>> can see there is no open boundaries file for eta...
>>>
>>> thank you,
>>> regards
>>> rima
>>>
>>>
>>> Send instant messages to your online friends http://
>>> uk.messenger.yahoo.com
>>> _______________________________________________
>>> MITgcm-support mailing list
>>> MITgcm-support at mitgcm.org
>>> http://mitgcm.org/mailman/listinfo/mitgcm-support
>>
>>
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Fri, 02 Mar 2007 10:03:16 +0100
>> From: Martin Losch <Martin.Losch at awi.de>
>> Subject: Re: [MITgcm-support] KPP & OB file
>> To: mitgcm-support at mitgcm.org
>> Message-ID: <143959B4-FFE7-4C22-A40C-87C82E87B209 at awi.de>
>> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
>>
>> Forgot to say: the model does the interpolation in time to each
>> timestep, but that's "only" a linear interpolation.
>> M.
>> On 2 Mar 2007, at 10:02, Martin Losch wrote:
>>
>>> Hi Riema,
>>>
>>> In order to use KPP you have to put "kpp" into your local
>>> packages.conf and you have to set #define SHORTWAVE_HEATING in your
>>> local CPP_OPTIONS.h because kpp requires a two band incoming
>>> radiation (short wave= visible light and long wave = the remaining
>>> part). The model will stop if you don't have short wave heating
>>> defined.
>>> You don't need to set any other parameters, unless you are unhappy
>>> with the choice of default values for, say, Ricr, etc. (see
>>> kpp_readparms.F). I have never changed them so far, but it's
>>> possible. KPP then compute vertical mixing coefficients etc based
>>> on your present vertical stratification, vertical shear, surface
>>> fluxes, etc. (see, eg., Large et al 1994 for details)
>>>
>>> OBCS:
>>> exp4 gives an example of how to specify CONSTANT (in time) open
>>> boundary values from files:
>>> useOBCSprescribe = .TRUE., (enables reading from files in general)
>>> OBNuFile = 'OBmeridU.bin', (example of a file)
>>> [...]
>>> these files were generated with exp4/input/gendata.m. The script
>>> tell you that a filed for the northern (southern) boundary should
>>> have the dimension (nx,nr) and for eastern (western), (ny,nr).
>>>
>>> If you want to specify time dependent boundary values you can do
>>> that too. For example, you have hourly data you have create a field
>>> (nx,nr,nt), where nt is the number of "hours" you have. and then
>>> you use the parameters
>>> periodicExternalForcing=.TRUE.,
>>> externForcingPeriod=3600.,
>>> in the file "data", in namelist PARM03. If your data is the same
>>> after say 12 hour (ie., that you want to use the fields repeatedly)
>>> then add this parameter in data
>>> externForcingCycle=43200.,
>>> These parameters that control reading external forcing data (also
>>> surface forcing if you use any) in general. the drawback is that
>>> all forcing data have to be at the exact same time levels. The
>>> advantage is , that it's simple.
>>> The alternative is to use the exf-package, where you can use
>>> different frequencies etc for different input fields, but it's also
>>> far more complicated.
>>>
>>> Does that help?
>>>
>>> M
>>>
>>> On 2 Mar 2007, at 02:45, Riema Rachmayani wrote:
>>>
>>>> thanks martin for KPP...KPP is special in that you have to set
>>>> #define SHORTWAVE_HEATING in CPP_OPTIONS.h in addtion...so you
>>>> mean that KPP is used ONLY when we define shortwave_heating??so i
>>>> dont need to change Ricr for my internal wave case...because i
>>>> thought it influence of dynamic stability...
>>>>
>>>> one more question :
>>>>
>>>> now i'd like to ask about open boundaries file, as in \verification
>>>> \exp4\input\data.obcs :
>>>>
>>>> # Open-boundaries
>>>> &OBCS_PARM01
>>>> OB_Jnorth=80*-1,
>>>> OB_Jsouth=80*1,
>>>> OB_Ieast=42*-1,
>>>> OB_Iwest=42*1,
>>>> #useOrlanskiNorth=.TRUE.,
>>>> #useOrlanskiSouth=.TRUE.,
>>>> #useOrlanskiEast=.TRUE.,
>>>> #useOrlanskiWest=.FALSE.,
>>>> useOBCSprescribe = .TRUE.,
>>>> OBNuFile = 'OBmeridU.bin',
>>>> OBSuFile = 'OBmeridU.bin',
>>>> OBWuFile = 'OBzonalU.bin',
>>>> OBEuFile = 'OBzonalU.bin',
>>>> OBWsFile = 'OBzonalS.bin',
>>>> OBWptrFile(1) = 'OBzonalS.bin',
>>>> &
>>>> # Orlanski parameters
>>>> &OBCS_PARM02
>>>> #Cmax=0.45,
>>>> #cVelTimeScale=1000.,
>>>> &
>>>>
>>>> in the blue line means that data open boundaries is given from
>>>> data observation/prediction?? may i know how to read and to write
>>>> (format) for that open bondaries file?? is the data read every
>>>> time step or every one hour??how to interpolate them?? in what
>>>> routines that files read??
>>>>
>>>> in my case, i'm gonna use tidal prediction data of eta (elevation)
>>>> from ORITIDE from Ocean Research Instute, University of Tokyo, the
>>>> data is in every one hour, and usually we use spline cubic
>>>> subroutine to interpolated one hour data become every time step
>>>> data, so that every time step data/value used for open boundaries
>>>> input/value...how to modify my case in MITgcm?? because as far i
>>>> can see there is no open boundaries file for eta...
>>>>
>>>> thank you,
>>>> regards
>>>> rima
>>>>
>>>>
>>>> Send instant messages to your online friends http://
>>>> uk.messenger.yahoo.com
>>>> _______________________________________________
>>>> 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
>>
>>
>>
>> ------------------------------
>>
>> Message: 4
>> Date: Fri, 02 Mar 2007 10:03:51 +0100
>> From: ivane pairaud <ivane.pairaud at hmg.inpg.fr>
>> Subject: [MITgcm-support] effective viscosity
>> To: mitgcm-support at mitgcm.org
>> Message-ID: <45E7E877.5000101 at hmg.inpg.fr>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>> Hello,
>>
>> In the model we prescribe some viscosity coefficients. But as we want to
>> compute some length scales depending on the viscosity (in particular, in
>> the case of internal tides generated over a continental slope, the
>> thickness of an oscillating boundary layer), we want to know about the
>> effective viscosity in the model.
>> Do you know how we can manage to compute it?
>>
>> I'd appreciate any suggestions.
>> Thanks,
>>
>> Ivane
>>
>>
>> --
>> Ivane PAIRAUD
>> Laboratoire des Ecoulements Géophysiques et Industriels
>> BP 53 38041 Grenoble cdx 9 France
>> tél : +33 4 76 82 50 45 - fax : +33 4 76 82 52 71
>>
>>
>> ------------------------------
>>
>> Message: 5
>> Date: Fri, 02 Mar 2007 11:19:24 +0100
>> From: Jan Saynisch <jsaynisch at awi-bremerhaven.de>
>> Subject: [MITgcm-support] runtime error
>> To: mitgcm-support at mitgcm.org
>> Message-ID: <45E7FA2C.7000309 at awi-bremerhaven.de>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>> Hello
>>
>> I've encountered the following error after approx fifty years of model
>> run on a Linux cluster:
>>
>> (PID.TID 0000.0001) *** ERROR *** MNC_GET_NEXT_EMPTY_IND: array size
>> 200 exceeded--try increasing MNC_MAX_ID
>> (PID.TID 0000.0001) *** ERROR *** MNC_GET_NEXT_EMPTY_IND: occurred
>> within the 'mnc_f_names' array
>> ABNORMAL END: S/R MNC_GET_NEXT_EMPTY_IND
>> 3408.440u 533.780s 5:40:02.32 19.3% 0+0k 0+0io 354pf+0w
>>
>> What goes wrong here?
>> Thank you - Jan
>>
>> My configuration is as follows (packages & SIZE.h & data):
>>
>> &PACKAGES
>> useGMRedi=.TRUE.,
>> #usePTRACERS=.TRUE.,
>> useMNC=.TRUE.,
>> useSBO=.TRUE.,
>> &
>> ********************************************************************
>>
>> PARAMETER (
>> & sNx = 45,
>> & sNy = 40,
>> & OLx = 2,
>> & OLy = 2,
>> & nSx = 2,
>> & nSy = 1,
>> & nPx = 1,
>> & nPy = 1,
>> & Nx = sNx*nSx*nPx,
>> & Ny = sNy*nSy*nPy,
>> & Nr = 15)
>>
>> C MAX_OLX - Set to the maximum overlap region size of any array
>> C MAX_OLY that will be exchanged. Controls the sizing of exch
>> C routine buufers.
>> INTEGER MAX_OLX
>> INTEGER MAX_OLY
>> PARAMETER ( MAX_OLX = OLx,
>> & MAX_OLY = OLy )
>> *************************************************************************
>>
>> # ====================
>> # | Model parameters |
>> # ====================
>> #
>> # Continuous equation parameters
>> &PARM01
>> tRef = 15*20.,
>> sRef = 15*35.,
>> viscAr=1.E-3,
>> viscAh=5.E5,
>> diffKhT=0.0,
>> diffKrT=3.E-5,
>> diffKhS=0.0,
>> diffKrS=3.E-5,
>> rhonil=1035.,
>> rotationPeriod=86400.,
>> gravity=9.81,
>> eosType ='JMD95P',
>> rigidLid=.FALSE.,
>> implicitFreeSurface=.TRUE.,
>> ivdc_kappa=100.,
>> implicitDiffusion=.TRUE.,
>> useOldFreezing=.TRUE.,
>> exactConserv = .true.,
>> useRealFreshWaterFlux=.TRUE.,
>> # turn on non-linear free surface
>> nonlinFreeSurf=4,
>> hFacInf=0.2,
>> hFacSup=2.0,
>> # end
>> useCDscheme=.TRUE.,
>> useNHMTerms=.TRUE.,
>> # turn on looped cells
>> hFacMin=.05,
>> hFacMindr=50.,
>> # set precision of data files
>> readBinaryPrec=32,
>> writeBinaryPrec=64,
>> &
>>
>> # Elliptic solver parameters
>> &PARM02
>> cg2dMaxIters=500,
>> cg2dTargetResidual=1.E-13,
>> &
>>
>> # Time stepping parameters
>> &PARM03
>> nIter0 = 0,
>> #nTimeSteps = 800000,
>> # 100 years of integration will yield a reasonable flow field
>> # startTime = 0.,
>> endTime = 3110400000.,
>> deltaTmom = 1200.0,
>> tauCD = 321428.,
>> deltaTtracer= 172800.0,
>> deltaTClock = 172800.0,
>> deltaTfreesurf = 172800.0,
>> abEps = 0.1,
>> pChkptFreq= 31104000.,
>> dumpFreq= 2592000.,
>> monitorFreq= 86400.,
>> # 2 months restoring timescale for temperature
>> tauThetaClimRelax = 5184000.0,
>> # 6 months restoring timescale for salinity
>> #tauSaltClimRelax = 15552000.0,
>> periodicExternalForcing=.TRUE.,
>> externForcingPeriod=2592000.,
>> externForcingCycle=31104000.,
>> &
>>
>> # Gridding parameters
>> &PARM04
>> usingCartesianGrid=.FALSE.,
>> usingSphericalPolarGrid=.TRUE.,
>> delR= 50., 70., 100., 140., 190.,
>> 240., 290., 340., 390., 440.,
>> 490., 540., 590., 640., 690.,
>> phiMin=-80.,
>> dySpacing=4.,
>> dxSpacing=4.,
>> &
>>
>> # Input datasets
>> &PARM05
>> bathyFile= 'bathymetry.bin',
>> hydrogThetaFile='lev_t.bin',
>> hydrogSaltFile= 'lev_s.bin',
>> zonalWindFile= 'trenberth_taux.bin',
>> meridWindFile= 'trenberth_tauy.bin',
>> thetaClimFile= 'lev_sst.bin',
>> saltClimFile= 'lev_sss.bin',
>> surfQFile= 'ncep_qnet.bin',
>> the_run_name= 'global_ocean.90x40x15',
>> # fresh water flux is turned off, uncomment next line to turn on
>> # (not recommened together with surface salinity restoring)
>> EmPmRFile= 'ncep_emp.bin',
>> &
>>
>>
>> ------------------------------
>>
>> Message: 6
>> Date: Fri, 02 Mar 2007 12:19:09 +0100
>> From: Martin Losch <Martin.Losch at awi.de>
>> Subject: Re: [MITgcm-support] runtime error
>> To: mitgcm-support at mitgcm.org
>> Message-ID: <C861830D-D91E-4199-A6DC-CA2376099C3F at awi.de>
>> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
>>
>> Hi,
>>
>> one may add, that this happens, when Jan is trying to write his 50th
>> pickup files (pickup_cd is written properly, but pickup.
>> 0000008640.t001.nc is not.)
>>
>> Martin
>>
>> On 2 Mar 2007, at 11:19, Jan Saynisch wrote:
>>
>>> Hello
>>>
>>> I've encountered the following error after approx fifty years of
>>> model run on a Linux cluster:
>>>
>>> (PID.TID 0000.0001) *** ERROR *** MNC_GET_NEXT_EMPTY_IND: array
>>> size 200 exceeded--try increasing MNC_MAX_ID
>>> (PID.TID 0000.0001) *** ERROR *** MNC_GET_NEXT_EMPTY_IND: occurred
>>> within the 'mnc_f_names' array
>>> ABNORMAL END: S/R MNC_GET_NEXT_EMPTY_IND
>>> 3408.440u 533.780s 5:40:02.32 19.3% 0+0k 0+0io 354pf+0w
>>>
>>> What goes wrong here?
>>> Thank you - Jan
>>>
>>> My configuration is as follows (packages & SIZE.h & data):
>>>
>>> &PACKAGES
>>> useGMRedi=.TRUE.,
>>> #usePTRACERS=.TRUE.,
>>> useMNC=.TRUE.,
>>> useSBO=.TRUE.,
>>> &
>>> ********************************************************************
>>>
>>> PARAMETER (
>>> & sNx = 45,
>>> & sNy = 40,
>>> & OLx = 2,
>>> & OLy = 2,
>>> & nSx = 2,
>>> & nSy = 1,
>>> & nPx = 1,
>>> & nPy = 1,
>>> & Nx = sNx*nSx*nPx,
>>> & Ny = sNy*nSy*nPy,
>>> & Nr = 15)
>>>
>>> C MAX_OLX - Set to the maximum overlap region size of any array
>>> C MAX_OLY that will be exchanged. Controls the sizing of exch
>>> C routine buufers.
>>> INTEGER MAX_OLX
>>> INTEGER MAX_OLY
>>> PARAMETER ( MAX_OLX = OLx,
>>> & MAX_OLY = OLy )
>>> **********************************************************************
>>> ***
>>>
>>> # ====================
>>> # | Model parameters |
>>> # ====================
>>> #
>>> # Continuous equation parameters
>>> &PARM01
>>> tRef = 15*20.,
>>> sRef = 15*35.,
>>> viscAr=1.E-3,
>>> viscAh=5.E5,
>>> diffKhT=0.0,
>>> diffKrT=3.E-5,
>>> diffKhS=0.0,
>>> diffKrS=3.E-5,
>>> rhonil=1035.,
>>> rotationPeriod=86400.,
>>> gravity=9.81,
>>> eosType ='JMD95P',
>>> rigidLid=.FALSE.,
>>> implicitFreeSurface=.TRUE.,
>>> ivdc_kappa=100.,
>>> implicitDiffusion=.TRUE.,
>>> useOldFreezing=.TRUE.,
>>> exactConserv = .true.,
>>> useRealFreshWaterFlux=.TRUE.,
>>> # turn on non-linear free surface
>>> nonlinFreeSurf=4,
>>> hFacInf=0.2,
>>> hFacSup=2.0,
>>> # end
>>> useCDscheme=.TRUE.,
>>> useNHMTerms=.TRUE.,
>>> # turn on looped cells
>>> hFacMin=.05,
>>> hFacMindr=50.,
>>> # set precision of data files
>>> readBinaryPrec=32,
>>> writeBinaryPrec=64,
>>> &
>>>
>>> # Elliptic solver parameters
>>> &PARM02
>>> cg2dMaxIters=500,
>>> cg2dTargetResidual=1.E-13,
>>> &
>>>
>>> # Time stepping parameters
>>> &PARM03
>>> nIter0 = 0,
>>> #nTimeSteps = 800000,
>>> # 100 years of integration will yield a reasonable flow field
>>> # startTime = 0.,
>>> endTime = 3110400000.,
>>> deltaTmom = 1200.0,
>>> tauCD = 321428.,
>>> deltaTtracer= 172800.0,
>>> deltaTClock = 172800.0,
>>> deltaTfreesurf = 172800.0,
>>> abEps = 0.1,
>>> pChkptFreq= 31104000.,
>>> dumpFreq= 2592000.,
>>> monitorFreq= 86400.,
>>> # 2 months restoring timescale for temperature
>>> tauThetaClimRelax = 5184000.0,
>>> # 6 months restoring timescale for salinity
>>> #tauSaltClimRelax = 15552000.0,
>>> periodicExternalForcing=.TRUE.,
>>> externForcingPeriod=2592000.,
>>> externForcingCycle=31104000.,
>>> &
>>>
>>> # Gridding parameters
>>> &PARM04
>>> usingCartesianGrid=.FALSE.,
>>> usingSphericalPolarGrid=.TRUE.,
>>> delR= 50., 70., 100., 140., 190.,
>>> 240., 290., 340., 390., 440.,
>>> 490., 540., 590., 640., 690.,
>>> phiMin=-80.,
>>> dySpacing=4.,
>>> dxSpacing=4.,
>>> &
>>>
>>> # Input datasets
>>> &PARM05
>>> bathyFile= 'bathymetry.bin',
>>> hydrogThetaFile='lev_t.bin',
>>> hydrogSaltFile= 'lev_s.bin',
>>> zonalWindFile= 'trenberth_taux.bin',
>>> meridWindFile= 'trenberth_tauy.bin',
>>> thetaClimFile= 'lev_sst.bin',
>>> saltClimFile= 'lev_sss.bin',
>>> surfQFile= 'ncep_qnet.bin',
>>> the_run_name= 'global_ocean.90x40x15',
>>> # fresh water flux is turned off, uncomment next line to turn on
>>> # (not recommened together with surface salinity restoring)
>>> EmPmRFile= 'ncep_emp.bin',
>>> &
>>> _______________________________________________
>>> MITgcm-support mailing list
>>> MITgcm-support at mitgcm.org
>>> http://mitgcm.org/mailman/listinfo/mitgcm-support
>>
>>
>>
>> ------------------------------
>>
>> Message: 7
>> Date: Fri, 2 Mar 2007 08:08:01 -0500
>> From: Patrick Heimbach <heimbach at MIT.EDU>
>> Subject: Re: [MITgcm-support] runtime error
>> To: mitgcm-support at mitgcm.org
>> Message-ID: <65D1A4BD-1A46-40AB-B01F-E91F9ADD26D8 at mit.edu>
>> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
>>
>> Jan and Martin,
>>
>> not entirely sure, but the array size 200 is associated to
>> MNC_MAX_FID (not MNC_MAX_ID as written in error message)
>> and is set in MNC_SIZE.h
>>
>> I think (though no doc on this) that it's a buffer that keeps
>> track of the mnc file name counters to ensure that it generates
>> a new filename counter every time it needs one
>> (see S/R MNC_GET_NEXT_EMPTY_IND in mnc_utils.F)
>>
>> So you could just up this number to expected MNC_MAX_FID
>> if you think that so many different names should have been created.
>> If not, wait for answer by the author of that package :o)
>>
>> -Patrick
>>
>>
>>
>> On Mar 2, 2007, at 5:19 AM, Jan Saynisch wrote:
>>
>>> Hello
>>>
>>> I've encountered the following error after approx fifty years of
>>> model run on a Linux cluster:
>>>
>>> (PID.TID 0000.0001) *** ERROR *** MNC_GET_NEXT_EMPTY_IND: array
>>> size 200 exceeded--try increasing MNC_MAX_ID
>>> (PID.TID 0000.0001) *** ERROR *** MNC_GET_NEXT_EMPTY_IND: occurred
>>> within the 'mnc_f_names' array
>>> ABNORMAL END: S/R MNC_GET_NEXT_EMPTY_IND
>>> 3408.440u 533.780s 5:40:02.32 19.3% 0+0k 0+0io 354pf+0w
>>>
>>> What goes wrong here?
>>> Thank you - Jan
>>>
>>> My configuration is as follows (packages & SIZE.h & data):
>>>
>>> &PACKAGES
>>> useGMRedi=.TRUE.,
>>> #usePTRACERS=.TRUE.,
>>> useMNC=.TRUE.,
>>> useSBO=.TRUE.,
>>> &
>>> ********************************************************************
>>>
>>> PARAMETER (
>>> & sNx = 45,
>>> & sNy = 40,
>>> & OLx = 2,
>>> & OLy = 2,
>>> & nSx = 2,
>>> & nSy = 1,
>>> & nPx = 1,
>>> & nPy = 1,
>>> & Nx = sNx*nSx*nPx,
>>> & Ny = sNy*nSy*nPy,
>>> & Nr = 15)
>>>
>>> C MAX_OLX - Set to the maximum overlap region size of any array
>>> C MAX_OLY that will be exchanged. Controls the sizing of exch
>>> C routine buufers.
>>> INTEGER MAX_OLX
>>> INTEGER MAX_OLY
>>> PARAMETER ( MAX_OLX = OLx,
>>> & MAX_OLY = OLy )
>>> **********************************************************************
>>> ***
>>>
>>> # ====================
>>> # | Model parameters |
>>> # ====================
>>> #
>>> # Continuous equation parameters
>>> &PARM01
>>> tRef = 15*20.,
>>> sRef = 15*35.,
>>> viscAr=1.E-3,
>>> viscAh=5.E5,
>>> diffKhT=0.0,
>>> diffKrT=3.E-5,
>>> diffKhS=0.0,
>>> diffKrS=3.E-5,
>>> rhonil=1035.,
>>> rotationPeriod=86400.,
>>> gravity=9.81,
>>> eosType ='JMD95P',
>>> rigidLid=.FALSE.,
>>> implicitFreeSurface=.TRUE.,
>>> ivdc_kappa=100.,
>>> implicitDiffusion=.TRUE.,
>>> useOldFreezing=.TRUE.,
>>> exactConserv = .true.,
>>> useRealFreshWaterFlux=.TRUE.,
>>> # turn on non-linear free surface
>>> nonlinFreeSurf=4,
>>> hFacInf=0.2,
>>> hFacSup=2.0,
>>> # end
>>> useCDscheme=.TRUE.,
>>> useNHMTerms=.TRUE.,
>>> # turn on looped cells
>>> hFacMin=.05,
>>> hFacMindr=50.,
>>> # set precision of data files
>>> readBinaryPrec=32,
>>> writeBinaryPrec=64,
>>> &
>>>
>>> # Elliptic solver parameters
>>> &PARM02
>>> cg2dMaxIters=500,
>>> cg2dTargetResidual=1.E-13,
>>> &
>>>
>>> # Time stepping parameters
>>> &PARM03
>>> nIter0 = 0,
>>> #nTimeSteps = 800000,
>>> # 100 years of integration will yield a reasonable flow field
>>> # startTime = 0.,
>>> endTime = 3110400000.,
>>> deltaTmom = 1200.0,
>>> tauCD = 321428.,
>>> deltaTtracer= 172800.0,
>>> deltaTClock = 172800.0,
>>> deltaTfreesurf = 172800.0,
>>> abEps = 0.1,
>>> pChkptFreq= 31104000.,
>>> dumpFreq= 2592000.,
>>> monitorFreq= 86400.,
>>> # 2 months restoring timescale for temperature
>>> tauThetaClimRelax = 5184000.0,
>>> # 6 months restoring timescale for salinity
>>> #tauSaltClimRelax = 15552000.0,
>>> periodicExternalForcing=.TRUE.,
>>> externForcingPeriod=2592000.,
>>> externForcingCycle=31104000.,
>>> &
>>>
>>> # Gridding parameters
>>> &PARM04
>>> usingCartesianGrid=.FALSE.,
>>> usingSphericalPolarGrid=.TRUE.,
>>> delR= 50., 70., 100., 140., 190.,
>>> 240., 290., 340., 390., 440.,
>>> 490., 540., 590., 640., 690.,
>>> phiMin=-80.,
>>> dySpacing=4.,
>>> dxSpacing=4.,
>>> &
>>>
>>> # Input datasets
>>> &PARM05
>>> bathyFile= 'bathymetry.bin',
>>> hydrogThetaFile='lev_t.bin',
>>> hydrogSaltFile= 'lev_s.bin',
>>> zonalWindFile= 'trenberth_taux.bin',
>>> meridWindFile= 'trenberth_tauy.bin',
>>> thetaClimFile= 'lev_sst.bin',
>>> saltClimFile= 'lev_sss.bin',
>>> surfQFile= 'ncep_qnet.bin',
>>> the_run_name= 'global_ocean.90x40x15',
>>> # fresh water flux is turned off, uncomment next line to turn on
>>> # (not recommened together with surface salinity restoring)
>>> EmPmRFile= 'ncep_emp.bin',
>>> &
>>> _______________________________________________
>>> MITgcm-support mailing list
>>> MITgcm-support at mitgcm.org
>>> http://mitgcm.org/mailman/listinfo/mitgcm-support
>>
>> ---
>> Dr Patrick Heimbach | heimbach at mit.edu | http://www.mit.edu/~heimbach
>> MIT | EAPS, 54-1518 | 77 Massachusetts Ave | Cambridge, MA 02139, USA
>> FON: +1-617-253-5259 | FAX: +1-617-253-4464 | SKYPE: patrick.heimbach
>>
>>
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> MITgcm-support mailing list
>> MITgcm-support at mitgcm.org
>> http://mitgcm.org/mailman/listinfo/mitgcm-support
>>
>>
>> End of MITgcm-support Digest, Vol 45, Issue 3
>> *********************************************
>
More information about the MITgcm-support
mailing list