[MITgcm-support] MITgcm-support Digest, Vol 129, Issue 11
李志远
oceanlizy at 163.com
Sun Mar 9 07:02:56 EDT 2014
I think I learned so much, thank your for your advice ,Martin !
At 2014-03-07 21:16:53,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: abnormal with extreme temperature value (Martin Losch)
> 2. Run-time errors on Archer (Dan Jones)
> 3. Re: Run-time errors on Archer (Dan Jones)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Fri, 7 Mar 2014 09:32:59 +0100
>From: Martin Losch <Martin.Losch at awi.de>
>To: MITgcm Support <mitgcm-support at mitgcm.org>
>Subject: Re: [MITgcm-support] abnormal with extreme temperature value
>Message-ID: <01254850-F485-4A4B-BFC7-350F5F37FCB3 at awi.de>
>Content-Type: text/plain; charset="utf-8"
>
>Running the (or any) model at high resolution is always a little tricky because of stability. There is the cfl stabilitly for advection and then there are numerical stability criteria for viscosity and diffusion. Please have a look at one of the tutorials, where these numbers a discussed (briefly, e.g. here: <http://mitgcm.org/public/r2_manual/latest/online_documents/node129.html>), or at any numerical modelling textbook, e.g. Steve Griffies? book on Ocean Climate Modeling.
>
>I think that this
>> viscAh=4.E2,
>> diffKhT=4.E2,
>> diffKhS=4.E2,
>is the problem. I suggest to use a different set of parameters:
> viscAhGrid = 0.1,
># you?ll have to play a little with this parameter, but see pkg/mom_common/mom_calc_visc.F for more explanation, or the documentation <http://mitgcm.org/public/r2_manual/latest/online_documents/node85.html> for more options. Using the Leigth scheme is usually a good choice, which will allow you to run with probably the largest time steps possible
> diffKhT = 0.,
> diffKhS = 0.,
># that?s right, no explicit diffusion but then use a stable advection scheme with numerical diffusion to stabilize the run:
> tempAdvScheme = 33,
> saltAdvScheme = 33,
> staggerTimeStep = .TRUE.
># this is the DST3 scheme with flux limiting, see documentation.
>
>with these parameters, I am guess that you should be able to run with time steps timeStep = 600., or even more. (don?t use deltaTmom/deltaTtracer).
>
>Martin
>
>On Mar 7, 2014, at 8:56 AM, ??? <oceanlizy at 163.com> wrote:
>
>> From: Li zhiyuan <oceanlizy at 163.com
>> >
>> To: MITgcm <
>> mitgcm-support at mitgcm.org
>> >
>>
>> Subject:"abnormal with extreme temperature value "
>>
>> Hi,all;
>> I am running a model of semi-enclosed domain with 134x165x16 grid points . the model is driven by surface wind and heat flux .when I run my mitgcm model for some steps , very large temperature values occur ,then the model blows up .
>> the STDOUT file is as below :
>> (PID.TID 0005.0001) %MON time_tsnumber = 163
>> (PID.TID 0005.0001) %MON time_secondsf = 7.0416000000000E+06
>> (PID.TID 0005.0001) %MON dynstat_eta_max = 7.4690610491135E-01
>> (PID.TID 0005.0001) %MON dynstat_eta_min = -4.1593172249303E+00
>> (PID.TID 0005.0001) %MON dynstat_eta_mean = 2.0772424301492E-02
>> (PID.TID 0005.0001) %MON dynstat_eta_sd = 4.9627339137015E-01
>> (PID.TID 0005.0001) %MON dynstat_eta_del2 = 7.4943932050348E-04
>> (PID.TID 0005.0001) %MON dynstat_uvel_max = 3.5280025421360E+00
>> (PID.TID 0005.0001) %MON dynstat_uvel_min = -1.4035655480410E+00
>> (PID.TID 0005.0001) %MON dynstat_uvel_mean = -1.8326591842827E-02
>> (PID.TID 0005.0001) %MON dynstat_uvel_sd = 4.5870513051871E-02
>> (PID.TID 0005.0001) %MON dynstat_uvel_del2 = 9.8327354406657E-05
>> (PID.TID 0005.0001) %MON dynstat_vvel_max = 2.4380767316715E+00
>> (PID.TID 0005.0001) %MON dynstat_vvel_min = -2.3087621147168E+00
>> (PID.TID 0005.0001) %MON dynstat_vvel_mean = 3.4329723926579E-02
>> (PID.TID 0005.0001) %MON dynstat_vvel_sd = 9.0964738317473E-02
>> (PID.TID 0005.0001) %MON dynstat_vvel_del2 = 1.9834779107181E-04
>> (PID.TID 0005.0001) %MON dynstat_wvel_max = 2.6286782112003E-02
>> (PID.TID 0005.0001) %MON dynstat_wvel_min = -9.6061814986124E-02
>> (PID.TID 0005.0001) %MON dynstat_wvel_mean = 3.6700902646170E-05
>> (PID.TID 0005.0001) %MON dynstat_wvel_sd = 3.4462742242225E-03
>> (PID.TID 0005.0001) %MON dynstat_wvel_del2 = 7.4810854960120E-06
>> (PID.TID 0005.0001) %MON dynstat_theta_max = 5.7517891007917E+01
>> (PID.TID 0005.0001) %MON dynstat_theta_min = -1.0228097331456E+03
>> (PID.TID 0005.0001) %MON dynstat_theta_mean = 7.8087020365565E+00
>> (PID.TID 0005.0001) %MON dynstat_theta_sd = 6.2079576234231E+00
>> (PID.TID 0005.0001) %MON dynstat_theta_del2 = 1.3811582622522E-02
>> (PID.TID 0005.0001) %MON dynstat_salt_max = 3.5000000000152E+01
>> (PID.TID 0005.0001) %MON dynstat_salt_min = 3.4999999953140E+01
>> (PID.TID 0005.0001) %MON dynstat_salt_mean = 3.4999999999999E+01
>>
>> my data file :
>> # | Model parameters |
>> # ====================
>> #
>> # Continuous equation parameters
>> &PARM01
>> tRef = 16*20.,
>> sRef = 16*35.,
>> viscAz=1.E-4,
>> viscAh=4.E2,
>> diffKhT=4.E2,
>> diffKzT=3.E-5,
>> diffKhS=4.E2,
>> diffKzS=3.E-5,
>> rhoConst=1035.,
>> rhoConstFresh=1000.,
>> eosType = 'LINEAR',
>> ivdc_kappa=10.,
>> implicitDiffusion=.TRUE.,
>> allowFreezing=.FALSE.,
>> exactConserv=.TRUE.,
>> hFacMin=.3,
>> readBinaryPrec=32,
>> &
>>
>> # Elliptic solver parameters
>> &PARM02
>> cg2dMaxIters=500,
>> cg2dTargetResidual=1.E-13,
>> &
>>
>> # Time stepping parameters
>> &PARM03
>> nIter0 = 0,
>> nTimeSteps = 200,
>> deltaTmom = 30.,
>> deltaTtracer = 1200.,
>> deltaTClock = 43200.,
>> abEps = 0.1,
>> dumpFreq= 864000.,
>> monitorFreq=1.,
>> &
>>
>> # Gridding parameters
>> &PARM04
>> usingSphericalPolarGrid=.TRUE.,
>> delz= 10,20,25,30,50,100,100,
>> 200,300,400,500,500,500,
>> 500,500,500,
>> ygOrigin=24.500,
>> xgOrigin=117.525,
>> delX=134*0.1,
>> delY=165*0.1,
>> &
>>
>> # Input datasets
>> &PARM05
>> bathyFile= 'topo.bin',
>> hydrogThetaFile='t16.bin',
>> # hydrogSaltFile= 'Lev_clim_salt.bin',
>> # zonalWindFile= 'Taux.bin',
>> # meridWindFile= 'Tauy.bin',
>> #thetaClimFile= 'SST.bin',
>> # saltClimFile= 'SSS.bin',
>> &
>>
>> I guess it blow up because mixing coefficients or advection scheme in my model is incorrect , how I can avoid such problems ?
>>
>> any quick reply is great appreciated !
>> lizhi
>>
>>
>> _______________________________________________
>> MITgcm-support mailing list
>> MITgcm-support at mitgcm.org
>> http://mitgcm.org/mailman/listinfo/mitgcm-support
>
>
>
>
>------------------------------
>
>Message: 2
>Date: Fri, 7 Mar 2014 13:12:23 +0000
>From: Dan Jones <dcjones.work at gmail.com>
>To: mitgcm-support at mitgcm.org
>Subject: [MITgcm-support] Run-time errors on Archer
>Message-ID:
> <CAPj3iHTi__dunCGo+gxc45WMraarMMnPOWsWVtdG6fM0fShUMg at mail.gmail.com>
>Content-Type: text/plain; charset="iso-8859-1"
>
>Greetings:
>
>I am having trouble getting MITgcm to run on Archer. I am using the Intel
>compiler (14.0.1.106) with the following defines/flags in the build options
>file:
>
>DEFINES='-DALLOW_USE_MPI -DALWAYS_USE_MPI -D_BYTESWAPIO -DWORDLENGTH=4
>-DHAVE_FLUSH'
>LIBS='-L${CRAY_MPICH2_DIR}/lib -L${HDF5_DIR}/lib -L$NETCDF_DIR/lib -lnetcdf
>-lnetcdff -lhdf5 -lhdf5_hl'
>INCLUDES='-I${CRAY_MPICH2_DIR}/include -I${HDF5_DIR}/include
>-I${NETCDF_DIR}/include -I${HDF5_INCLUDE_OPTS}'
>FFLAGS='-h byteswapio -assume byterecl -convert big_endian -heap-arrays -O2
>-g -traceback'
>
>The code compiles with no errors, but it does not run. The code crashes
>with the error:
>
>ABNORMAL END: S/R INI_THETA
>
>with no other information. The initial theta file is fine and has been
>used successfully in other MITgcm model setups. When I turn on the
>debugger (i.e. set debugMode=.TRUE. in input/eedata and set the
>debugLevel=4 in input/data), I get a *different* error that appears to
>occur in an *earlier* part of the code. The code crashes as it tries to
>read in the bathymetry file:
>
>forrtl: error (63): output conversion error, unit -5, file Internal
>Formatted Write
>
>
>Image PC Routine Line
>Source
>mitgcmuv 00000000023CCCBC print_maprs_ 4981 print.f
>mitgcmuv 000000000297FD81 plot_field_xyrs_ 1841 plot_field.f
>mitgcmuv 000000000276CDC2 ini_depths_ 3271 ini_depths.f
>mitgcmuv 0000000002932628 initialise_fixed_ 1908
>initialise_fixed.f
>mitgcmuv 0000000002B03175 the_model_main 3052 the_model_main.f
>mitgcmuv 00000000023A38F1 MAIN__ 4407 main.f
>
>Again, the bathymetry file is fine and has been used successfully before.
>The problem indicated above in ini_depths.f happens in this function:
>
> CALL PRINT_LIST_I( OB_Jnorth, 1, OBNS_Nx, INDEX_I,
> & .FALSE., .TRUE., standardMessageUnit )
>
>I can suppress the output conversion error by re-compiling with a -check
>nooutput_conversion flag, but the code quickly produces a segmentation
>fault at about the same place (ini_depths.f and the functions that call it):
>
>forrtl: severe (194): SIGSEGV, segmentation fault occurred
>
>mitgcmuv 00000000006FFAE7 print_maprs_ 4982 print.f
>mitgcmuv 00000000007950D3 plot_field_xyrs_ 1841
>plot_field.f
>mitgcmuv 0000000000760811 ini_depths_ 3271
>ini_depths.f
>mitgcmuv 000000000078699A initialise_fixed_ 1908
>initialise_fixed.f
>mitgcmuv 00000000007AFA93 the_model_main_ 3052
>the_model_main.f
>mitgcmuv 00000000006F5C41 MAIN__ 4407 main.f
>
>The fact that turning on the debugger produces an error *earlier* in the
>code is the most interesting/distressing bit here. Is this an I/O issue?
>Has anyone else run into something like this? I have contacted the Archer
>support team, but I thought it would be worth asking around here as well.
>
>Many thanks,
>Dan
>
>--
>*************************************************
>
>Dr Dan Jones
>Open Oceans Group
>British Antarctic Survey
>Cambridge, UK
>
>Phone: +44 (0)1223 221505
>Fax: +44 (0)1223 362616
>
>*************************************************
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL: <http://mitgcm.org/pipermail/mitgcm-support/attachments/20140307/40e459a9/attachment-0001.htm>
>
>------------------------------
>
>Message: 3
>Date: Fri, 7 Mar 2014 13:16:45 +0000
>From: Dan Jones <dcjones.work at gmail.com>
>To: mitgcm-support at mitgcm.org
>Subject: Re: [MITgcm-support] Run-time errors on Archer
>Message-ID:
> <CAPj3iHQJqocGZYF_dM6KS2BcWM-d06MKBf3j6xnPrJYH1tRV9Q at mail.gmail.com>
>Content-Type: text/plain; charset="iso-8859-1"
>
>Correction:
>
>The snippet of source code listed above actually comes from yet *another*
>error produced if the obcs package is included in packages.conf:
>
> forrtl: error (63): output conversion error, unit -5, file Internal
>Formatted Write
>Image PC Routine Line
>Source
>mitgcmuv 000000000302A3EA Unknown Unknown Unknown
>mitgcmuv 00000000023B5F85 print_list_i_ 3331 print.f
>mitgcmuv 0000000001A302E7 obcs_readparms_ 2425
>obcs_readparms.f
>mitgcmuv 000000000297EBF0 packages_readparm 1907
>packages_readparms.f
>mitgcmuv 0000000002932168 initialise_fixed_ 1874
>initialise_fixed.f
>mitgcmuv 0000000002B03175 the_model_main_ 3052
>the_model_main.f
>mitgcmuv 00000000023A38F1 MAIN__ 4407 main.f
>mitgcmuv 0000000000400F06 Unknown Unknown Unknown
>mitgcmuv 00000000030A8124 Unknown Unknown Unknown
>mitgcmuv 0000000000400DD1 Unknown Unknown Unknown
>
> IF ( debugLevel.GE.debLevA ) THEN
> CALL PRINT_LIST_I( OB_Jnorth, 1, OBNS_Nx, INDEX_I,
> & .FALSE., .TRUE., standardMessageUnit )
>
>It does *not* come from ini_depths, but from obcs_readparms. Sorry about
>that.
>
>Dan
>
>
>On Fri, Mar 7, 2014 at 1:12 PM, Dan Jones <dcjones.work at gmail.com> wrote:
>
>> Greetings:
>>
>> I am having trouble getting MITgcm to run on Archer. I am using the Intel
>> compiler (14.0.1.106) with the following defines/flags in the build options
>> file:
>>
>> DEFINES='-DALLOW_USE_MPI -DALWAYS_USE_MPI -D_BYTESWAPIO -DWORDLENGTH=4
>> -DHAVE_FLUSH'
>> LIBS='-L${CRAY_MPICH2_DIR}/lib -L${HDF5_DIR}/lib -L$NETCDF_DIR/lib
>> -lnetcdf -lnetcdff -lhdf5 -lhdf5_hl'
>> INCLUDES='-I${CRAY_MPICH2_DIR}/include -I${HDF5_DIR}/include
>> -I${NETCDF_DIR}/include -I${HDF5_INCLUDE_OPTS}'
>> FFLAGS='-h byteswapio -assume byterecl -convert big_endian -heap-arrays
>> -O2 -g -traceback'
>>
>> The code compiles with no errors, but it does not run. The code crashes
>> with the error:
>>
>> ABNORMAL END: S/R INI_THETA
>>
>> with no other information. The initial theta file is fine and has been
>> used successfully in other MITgcm model setups. When I turn on the
>> debugger (i.e. set debugMode=.TRUE. in input/eedata and set the
>> debugLevel=4 in input/data), I get a *different* error that appears to
>> occur in an *earlier* part of the code. The code crashes as it tries to
>> read in the bathymetry file:
>>
>> forrtl: error (63): output conversion error, unit -5, file Internal Formatted Write
>>
>>
>> Image PC Routine Line
>> Source
>> mitgcmuv 00000000023CCCBC print_maprs_ 4981 print.f
>> mitgcmuv 000000000297FD81 plot_field_xyrs_ 1841 plot_field.f
>> mitgcmuv 000000000276CDC2 ini_depths_ 3271 ini_depths.f
>> mitgcmuv 0000000002932628 initialise_fixed_ 1908
>> initialise_fixed.f
>> mitgcmuv 0000000002B03175 the_model_main 3052 the_model_main.f
>> mitgcmuv 00000000023A38F1 MAIN__ 4407 main.f
>>
>> Again, the bathymetry file is fine and has been used successfully before.
>> The problem indicated above in ini_depths.f happens in this function:
>>
>> CALL PRINT_LIST_I( OB_Jnorth, 1, OBNS_Nx, INDEX_I,
>> & .FALSE., .TRUE., standardMessageUnit )
>>
>> I can suppress the output conversion error by re-compiling with a -check
>> nooutput_conversion flag, but the code quickly produces a segmentation
>> fault at about the same place (ini_depths.f and the functions that call it):
>>
>> forrtl: severe (194): SIGSEGV, segmentation fault occurred
>>
>> mitgcmuv 00000000006FFAE7 print_maprs_ 4982 print.f
>> mitgcmuv 00000000007950D3 plot_field_xyrs_ 1841 plot_field.f
>>
>> mitgcmuv 0000000000760811 ini_depths_ 3271 ini_depths.f
>> mitgcmuv 000000000078699A initialise_fixed_ 1908 initialise_fixed.f
>> mitgcmuv 00000000007AFA93 the_model_main_ 3052 the_model_main.f
>>
>> mitgcmuv 00000000006F5C41 MAIN__ 4407 main.f
>>
>> The fact that turning on the debugger produces an error *earlier* in the
>> code is the most interesting/distressing bit here. Is this an I/O issue?
>> Has anyone else run into something like this? I have contacted the Archer
>> support team, but I thought it would be worth asking around here as well.
>>
>> Many thanks,
>> Dan
>>
>> --
>> *************************************************
>>
>> Dr Dan Jones
>> Open Oceans Group
>> British Antarctic Survey
>> Cambridge, UK
>>
>> Phone: +44 (0)1223 221505
>> Fax: +44 (0)1223 362616
>>
>> *************************************************
>>
>
>
>
>--
>*************************************************
>
>Dr Dan Jones
>Open Oceans Group
>British Antarctic Survey
>Cambridge, UK
>
>Phone: +44 (0)1223 221505
>Fax: +44 (0)1223 362616
>
>*************************************************
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL: <http://mitgcm.org/pipermail/mitgcm-support/attachments/20140307/b760cdba/attachment.htm>
>
>------------------------------
>
>_______________________________________________
>MITgcm-support mailing list
>MITgcm-support at mitgcm.org
>http://mitgcm.org/mailman/listinfo/mitgcm-support
>
>
>End of MITgcm-support Digest, Vol 129, Issue 11
>***********************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mitgcm.org/pipermail/mitgcm-support/attachments/20140309/f6d2fa94/attachment-0001.htm>
More information about the MITgcm-support
mailing list