[MITgcm-support] MITgcm-support Digest, Vol 194, Issue 17
David Vishny
davidvish at gmail.com
Mon Aug 26 12:50:25 EDT 2019
Hi Martin,
-My model version is 1.2242.
-From the working configuration, I changed the grid from 72 x 140 x 29 to 128 x 64 x 15 (as in the biogeochemistry tutorial), and went from 4 x 7 processors to 4 x 4 processors.
-I also switched from simplified topography to the realistic global topography of the biogeochem tutorial, modified the EXF forcing files, and changed all the viscosities and diffusivities in the “data" file to match those in the analogous file from the biogeochemistry tutorial.
-To avoid numerical instability during testing, I made the time-steps very tiny, switching from 14400 to 3200.
-I’ve attached two namelist files and three code directory files that might be relevant to understand my setup.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: packages.conf
Type: application/octet-stream
Size: 225 bytes
Desc: not available
URL: <http://mailman.mitgcm.org/pipermail/mitgcm-support/attachments/20190826/fd420948/attachment-0005.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: data.seaice
Type: application/octet-stream
Size: 1084 bytes
Desc: not available
URL: <http://mailman.mitgcm.org/pipermail/mitgcm-support/attachments/20190826/fd420948/attachment-0006.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: data
Type: application/octet-stream
Size: 2664 bytes
Desc: not available
URL: <http://mailman.mitgcm.org/pipermail/mitgcm-support/attachments/20190826/fd420948/attachment-0007.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CPP_OPTIONS.h
Type: application/octet-stream
Size: 3816 bytes
Desc: not available
URL: <http://mailman.mitgcm.org/pipermail/mitgcm-support/attachments/20190826/fd420948/attachment-0008.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SEAICE_OPTIONS.h
Type: application/octet-stream
Size: 7439 bytes
Desc: not available
URL: <http://mailman.mitgcm.org/pipermail/mitgcm-support/attachments/20190826/fd420948/attachment-0009.obj>
-------------- next part --------------
Thanks,
David
> On Aug 24, 2019, at 2:01 AM, 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://mailman.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: Sea ice dynamics causing model to output NaN's after
> changing grid configuration (Martin Losch)
> 2. Re: Reading errors (kaveh Purkiani)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 24 Aug 2019 08:55:57 +0200
> From: Martin Losch <Martin.Losch at awi.de>
> To: <mitgcm-support at mitgcm.org>
> Subject: Re: [MITgcm-support] Sea ice dynamics causing model to output
> NaN's after changing grid configuration
> Message-ID: <2129627E-3B99-43CB-A277-57C245DABE04 at awi.de>
> Content-Type: text/plain; charset="utf-8"
>
> Hi David,
> I would need more details to be able to help. Configuration (code directory, namelist files, version of model), and what exactly you changed from a working configuration
>
> Martin
>
>> On 24. Aug 2019, at 00:07, David Vishny <davidvish at gmail.com> wrote:
>>
>> To whom it may concern,
>>
>> I recently changed the grid configuration in my model setup, and now the model outputs all NaN?s after a single time-step if sea ice dynamics are enabled, even though there is no sea ice to begin with. If I disable sea ice dynamics, it appears that no problems occur. Thus, my advisor Malte Jansen and I believe the LSR solver is producing NaN?s.
>>
>> I know one parameter related to the LSR solver is the LSR error. For any given grid configuration, could the solver crash due to an LSR error that is either too high or too low? Are there any other parameters I should be playing around with that are related to the LSR solver?
>>
>>
>> Thanks,
>>
>> David Vishny
>> _______________________________________________
>> MITgcm-support mailing list
>> MITgcm-support at mitgcm.org
>> http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support
>
>
> ------------------------------
>
> Message: 2
> Date: Sat, 24 Aug 2019 09:01:13 +0200
> From: kaveh Purkiani <kavehpurkiani at googlemail.com>
> To: mitgcm-support at mitgcm.org
> Subject: Re: [MITgcm-support] Reading errors
> Message-ID:
> <CA+SSPLANdmxLwmqrZzSyRm=TgU4z7sunFcWZwuQV1UyqH5fTfw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Estanislao,
>
> Could you try the Matlab code once again with prec=real*8 and see if model
> crashes again?
>
> regards
> Kaveh
>
> On Sat 24. Aug 2019 at 03:09, Estanislao Gavilan Pascual-Ahuir <
> dramauh at hotmail.com> wrote:
>
>> Hi Martin
>>
>> I am not sure if that is the problem because I used readbin.m to check
>> the input files and the matrix were correct. This is the MATLAB code I
>> used.
>> % creat N time slabs for testing
>> ieee='b';
>> prec='real*4';
>> v0=0.0041;
>> N=100
>> vvel=ones(13,2,N);
>> uMerid=zeros(13,2,N);
>> for i=1:N
>> vZonal(:,:,i)=v0*vvel(:,:,i)*i/N;
>> end
>> fid=fopen('OBmeridU.bin','w',ieee); fwrite(fid,uMerid,prec);fclose(fid);
>> fid=fopen('OBzonalV.bin','w',ieee); fwrite(fid,vZonal,prec); fclose(fid);
>>
>> I have even tried to use your code, but the files do not change the size.
>> They are always 11KB
>>
>> % creat N time slabs for testing
>> v0=0.0041;
>> N=100
>> vvel=ones(13,2,N);
>> uMerid=zeros(13,2,N);
>> for i=1:N
>> vZonal(:,:,i)=v0*vvel(:,:,i)*i/N;
>> end
>> fid=fopen('OBmeridU.bin','w',ieee);
>> for i=1:N
>> fwrite(fid,squeeze(uMerid(:,:,i)),prec);
>> end
>> fclose(fid);
>> fid=fopen('OBzonalV.bin','w',ieee);
>> for i=1:N
>> fwrite(fid,squeeze(vZonal(:,:,i)),prec);
>> end
>> fclose(fid);
>>
>> Kind regards,
>>
>> Estanislao
>>
>> ------------------------------
>> *De:* MITgcm-support <mitgcm-support-bounces at mitgcm.org> en nombre de
>> mitgcm-support-request at mitgcm.org <mitgcm-support-request at mitgcm.org>
>> *Enviado:* viernes, 23 de agosto de 2019 18:00
>> *Para:* mitgcm-support at mitgcm.org <mitgcm-support at mitgcm.org>
>> *Asunto:* MITgcm-support Digest, Vol 194, Issue 14
>>
>> Send MITgcm-support mailing list submissions to
>> mitgcm-support at mitgcm.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> http://mailman.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: Reading errors (Martin Losch)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Fri, 23 Aug 2019 10:02:49 +0200
>> From: Martin Losch <Martin.Losch at awi.de>
>> To: MITgcm Support <mitgcm-support at mitgcm.org>
>> Subject: Re: [MITgcm-support] Reading errors
>> Message-ID: <1AB158B6-A07E-43EB-A3F6-6530BDE345C9 at awi.de>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Hi Estanis,
>>
>> this most likely means that your OBzonalV.bin is ?too short?.
>> Guess from you parameters you'll need fields with dimension (nt,nz,nx) =
>> (100,2,43). In you data file you do not specify the ?readBinaryPrec?, so
>> that will default to ?real*4?, single precision, ?float32?, but check in
>> your stdout, so in python this would mean writing a file like this:
>>
>> import numpy as np
>> import sys
>> nt=100
>> nx=43
>> nz=2
>>
>> data = np.zeros((nt,nz,nx),dtype=?float32') # or some other values, but
>> dtype is important
>> if sys.byteorder == 'little': data.byteswap(True)
>> #
>> fid = open(?OBzonalV.bin',"wb")
>> data.tofile(fid)
>> fid.close()
>> # switch back to machine format
>> if sys.byteorder == 'little': data.byteswap(True)
>>
>> With this I get a file of this size:
>>
>>>>> du -h ./OBzonalV.bin
>> 36K ./OBzonalV.bin
>>
>>>>> ls -l OBzonalV.bin
>> -rw-r--r-- 1 mlosch DMAWI\KLI04 34400 Aug 23 09:53 OBzonalV.bin
>>
>>
>> # in matlab it would be similar, but note the different order of
>> dimensions:
>> data = zeros(nx,nz,nt);
>> accuracy = ?real*4?;
>> [fid message] = fopen(?OBzonalV.bin','w','ieee-be');
>> count = fwrite(fid,data,accuracy);
>> for k=1:nt
>> fwrite(fid,squeeze(data(:,:,k)),accuracy);
>> end
>> fclose(fid);
>>
>>
>>
>> About the NETCDF_ROOT and other INCLUDES: this file is meant to be as
>> generic as possible, i.e. the code at the end of the build options file
>> will look for paths in the usual places. In 95% of the cases this works. If
>> you have a special installation, you might want to hard-wire the paths, as
>> you have done, then you don?t need the rest anymore. Alternatively you
>> could set the environment varialbes NETCDF_ROOT and MPI_INC_DIR, e.g. like
>> this
>>
>> export NETCDF_ROOT=/WORK/app/netcdf/4.3.2/01-CF-14/
>> export MPI_INC_DIR=/usr/local/mpi3-dynamic/include
>>
>> ***before*** you run genmake2, then it should work, too.
>>
>> Martin
>>
>>> On 23. Aug 2019, at 04:37, Estanislao Gavilan Pascual-Ahuir <
>> dramauh at hotmail.com> wrote:
>>>
>>>
>>> Hi Martin and Jean-Michel
>>> I still have the error forrtl: severe (36): attempt to access
>> non-existent record, unit 16, file /bblablabla/run/OBzonalV.bin. In
>> addition, I saw this message after doing make depend f90mkdepend: no source
>> file found for module this. I am no sure if this is important.
>>>
>>> I followed your advice. I start doing a simulation in serial mode
>> without obcs and the model ran perfectly fine. Once I opened the obcs (i.e.
>> useOBCS= TRUE), I had that error. Following the architecture of my cluster
>> change a little bit the linux_ia64_ifort. By the way, do I need the last
>> set of conditions of NETCDF_ROOT and netcdf test? I was thinking to remove
>> them.
>>>
>>> Kind regards,
>>>
>>> Estanis
>>>
>>> #!/bin/bash
>>> #
>>> # Tested on uv100.awi.de (SGI UV 100, details:
>>> #
>> http://www.sgi.com/products/servers/uv/specs.html)
>>> # a) For more speed, provided your data size does not exceed 2GB you can
>>> # remove -fPIC which carries a performance penalty of 2-6%.
>>> # b) You can replace -fPIC with '-mcmodel=medium -shared-intel' which may
>>> # perform faster than -fPIC and still support data sizes over 2GB per
>>> # process but all the libraries you link to must be compiled with
>>> # -fPIC or -mcmodel=medium
>>> # c) flags adjusted for ifort 12.1.0
>>>
>>> FC=ifort
>>> F90C=ifort
>>> CC=icc
>>> # requires that all static libraries are available:
>>> #LINK='ifort -static'
>>> LINK='ifort'
>>> # for adjoint runs the default makedepend often cannot handle enough
>> files
>>> #MAKEDEPEND=tools_xmakedepend
>>>
>>> DEFINES='-DWORDLENGTH=4'
>>> CPP='cpp -traditional -P'
>>> F90FIXEDFORMAT='-fixed -Tf'
>>> EXTENDED_SRC_FLAG='-132'
>>> #OMPFLAG='-openmp'
>>>
>>> NOOPTFLAGS="-O0 -g -m64"
>>> NOOPTFILES=''
>>>
>>> MCMODEL='-fPIC'
>>> # for large memory requirements uncomment this line
>>> #MCMODEL='-mcmodel=medium -shared-intel'
>>>
>>> FFLAGS="$FFLAGS -W0 -WB -convert big_endian -assume byterecl $MCMODEL"
>>> #- might want to use '-r8' for fizhi pkg:
>>> #FFLAGS="$FFLAGS -r8"
>>>
>>> if test "x$IEEE" = x ; then #- with optimisation:
>>> FOPTIM='-O3 -align'
>>> # does not work when -static does not work
>>> # FOPTIM='-fast -align'
>>> # instead you can use
>>> # FOPTIM='-O3 -ipo -align'
>>> else
>>> if test "x$DEVEL" = x ; then #- no optimisation + IEEE :
>>> FOPTIM='-O0 -noalign -fp-model precise'
>>> # -fltconsistency
>>> else #- development/check options:
>>> FOPTIM='-O0 -noalign -fp-model precise'
>>> FOPTIM="$FOPTIM -g -check all -fpe0 -traceback -ftrapuv -fp-model
>> except -warn all"
>>> fi
>>> fi
>>>
>>> F90FLAGS=$FFLAGS
>>> F90OPTIM=$FOPTIM
>>> CFLAGS="-O0 -ip $MCMODEL"
>>>
>>> INCLUDEDIRS=''
>>> INCLUDES='-I. -I$NETCDF/include
>> -I/WORK/app/netcdf/4.3.2/01-CF-14/include -I/usr/local/mpi3-dynamic/include'
>>> LIBS='-L$NETCDF/lib -lnetcdff -lnetcdf
>> -I/WORK/app/netcdf/4.3.2/01-CF-14/lib'
>>>
>>> if [ "x$NETCDF_ROOT" != x ] ; then
>>> INCLUDEDIRS="${NETCDF_ROOT}/include"
>>> INCLUDES="-I${NETCDF_ROOT}/include"
>>> LIBS="-L${NETCDF_ROOT}/lib"
>>> elif [ "x$NETCDF_HOME" != x ]; then
>>> INCLUDEDIRS="${NETCDF_HOME}/include"
>>> INCLUDES="-I${NETCDF_HOME}/include"
>>> LIBS="-L${NETCDF_HOME}/lib"
>>> elif [ "x$NETCDF_INC" != x -a"x$NETCDF_LIB" != x ]; then
>>> NETCDF_INC=`echo $NETCDF_INC | sed 's/-I//g'`
>>> NETCDF_LIB=`echo $NETCDF_LIB | sed 's/-L//g'`
>>> INCLUDEDIRS="${NETCDF_INC}"
>>> INCLUDES="-I${NETCDF_INC}"
>>> LIBS="-L${NETCDF_LIB}"
>>> elif [ "x$NETCDF_INCDIR" != x -a "x$NETCDF_LIBDIR" != x ]; then
>>> INCLUDEDIRS="${NETCDF_INCDIR}"
>>> INCLUDES="-I${NETCDF_INCDIR}"
>>> LIBS="-L${NETCDF_LIBDIR}"
>>> elif test -d /usr/include/netcdf-3 ; then
>>> INCLUDEDIRS='/usr/include/netcdf-3'
>>> INCLUDES='-I/usr/include/netcdf-3'
>>> LIBS='-L/usr/lib/netcdf-3 -L/usr/lib64/netcdf-3'
>>> elif test -d /usr/include/netcdf ; then
>>> INCLUDEDIRS='/usr/include/netcdf'
>>> INCLUDES='-I/usr/include/netcdf'
>>> elif test -d /usr/local/netcdf ; then
>>> INCLUDEDIRS='/usr/include/netcdf/include'
>>> INCLUDES='-I/usr/local/netcdf/include'
>>> LIBS='-L/usr/local/netcdf/lib'
>>> elif test -d /usr/local/include/netcdf.inc ; then
>>> INCLUDEDIRS='/usr/local/include'
>>> INCLUDES='-I/usr/local/include'
>>> LIBS='-L/usr/local/lib64'
>>> fi
>>>
>>> if [ -n "$MPI_INC_DIR" -a "x$MPI" = xtrue ] ; then
>>> LIBS="$LIBS -lmpi"
>>> INCLUDES="$INCLUDES -I$MPI_INC_DIR"
>>> INCLUDEDIRS="$INCLUDEDIRS $MPI_INC_DIR"
>>> #- used for parallel (MPI) DIVA
>>> MPIINCLUDEDIR="$MPI_INC_DIR"
>>> fi
>>>
>>>
>>> ----------------------------------------------------------------------
>>>
>>> Message: 1
>>> Date: Thu, 22 Aug 2019 13:10:55 +0200
>>> From: Martin Losch <Martin.Losch at awi.de>
>>> To: MITgcm Support <mitgcm-support at mitgcm.org>
>>> Subject: Re: [MITgcm-support] Reading errors
>>> Message-ID: <325AC4E8-1648-4C6A-BFED-7722921C733E at awi.de>
>>> Content-Type: text/plain; charset="utf-8"
>>>
>>> Hi Estanis,
>>>
>>> thanks for the details. This is what I would do:
>>>
>>> - At the compile level use a standard build options file, with an intel
>> compiler on a linux system I would start with
>> MITgcm/tools/build_options/linux_amd64_ifort, or linux_ia64_ifort
>> (depending on the output of uname -a, in fact, genmake2 is probably able to
>> pick the correct file if you don?t specify it), and since your domain is
>> small I would first try without MPI, ie. like this:
>>>
>>> ${somepath}/tools/genmake2 -of
>> ${somepath}/tools/build_options/linux_amd64_ifort -mods ../code
>>> make CLEAN && make depend && make
>>>
>>> - With this non-MPI configuration I would try to run the model. First
>> with useOBCS=.FALSE. (just a few timesteps), and then with .TRUE.
>>>
>>> - once this works, you can recompile with MPI (if you really need it),
>> like this:
>>>
>>> ${somepath}/tools/genmake2 -of
>> ${somepath}/tools/build_options/linux_amd64_ifort -mods ../code -mpi
>>> make CLEAN && make depend && make
>>> (note that the extra flag ?-mpi" is enough)
>>>
>>> and check if you get the same. For further help, you should record the
>> potential error messages after each step.
>>>
>>> Martin
>>>
>>> PS. Some comments about your namelist below:
>>>
>>>> On 22. Aug 2019, at 12:39, Estanislao Gavilan Pascual-Ahuir <
>> dramauh at hotmail.com> wrote:
>>>>
>>>> Hi Martin ,
>>>>
>>>> Before anything thank you so much for your help. I will try to answer
>> all you questions.
>>>>
>>>> what is the platform, the compiler?
>>>> The platform in linux 2.6.32-431.TH.x86_64 GNU/Linux. Red Hat
>> Enterprise Linux Server release 6.5. I am using intel compilers wrapped
>> them in mpi. The version of the compiler is 14.0.2
>>>> details of the configuration (content of code-directory and namelist
>> files)
>>>> I am running a simple simulation with open boundaries. I load the
>> packages gfd, obcs, mnc and diagnostics using the packages.config. The
>> frequency of the open boundaries is stated in the data file. This is the
>> data file
>>>> Model parameters
>>>> # Continuous equation parameters
>>>> &PARM01
>>>> tRef=23.,23.,
>>>> sRef=35.,35.,
>>>> selectCoriMap=4,
>>>> viscAh=4.E2,
>>> with your grid choice (sphericalPolarGrid), the coriolis parameter is
>> computed and these values are not used.
>>>> f0=1.E-4,
>>>> beta=1.E-11,
>>>> rhoNil=1000.,
>>>> gBaro=9.81,
>>>> rigidLid=.FALSE.,
>>>> implicitFreeSurface=.TRUE.,
>>>> # momAdvection=.FALSE.,
>>>> tempStepping=.FALSE.,
>>>> saltStepping=.FALSE.,
>>>> &
>>>>
>>>> # Elliptic solver parameters
>>>> &PARM02
>>>> cg2dTargetResidual=1.E-7,
>>>> cg2dMaxIters=1000,
>>>> &
>>>>
>>>> # Time stepping parameters
>>>> &PARM03
>>>> nIter0=0,
>>>> nTimeSteps=100,
>>>> deltaT=1200.0,
>>>> pChkptFreq=31104000.0,
>>>> chkptFreq=15552000.0,
>>>> dumpFreq=15552000.0,
>>> # this will give you monitor output every timestep (which is what you
>> want while debugging), later I would set it to something like 20-50 * deltaT
>>>> monitorFreq=1200.,
>>>> monitorSelect=2,
>>>> periodicExternalForcing=.TRUE.,
>>> # this means that you will read data each time step. Is that what you
>> want?
>>>> externForcingPeriod= 1200.,
>>> # with your choice of externForcingPeriod, this requires that you have
>> 1000. records in the file(s)
>>>> externForcingCycle = 12000000.,
>>>> &
>>>> # Gridding parameters
>>>> &PARM04
>>>> usingSphericalPolarGrid=.TRUE.,
>>> # alternatively you can say dxSpacing = 1., dySpacing = 1.,
>>>> delX=43*1.,
>>>> delY=43*1.,
>>>> xgOrigin=-21.,
>>>> ygOrigin=-21.,
>>>> delR=2*500.,
>>>> &
>>>>
>>>> # Input datasets
>>>> &PARM05
>>>> bathyFile='bathy_cir.bin'
>>>> meridWindFile=,
>>>> &
>>>>
>>>> This is the data.obcs
>>>>
>>>> # Open-boundaries
>>>> &OBCS_PARM01
>>>> OBCSfixTopo=.FALSE.,
>>> # if I understand the configuration correctly, you have a zonally
>> reentrant channel with wall in the north and the south (python notation:
>> bathy[0+2,:] = 0, and bathy[ny-1,:] = 0, except where you have the open
>> boundaries)? you could actually save two grid rows (have 40 instead of 43
>> point in j-direction and set bathy[0,:]=0, bathy[ny,:]=0)
>>>> OB_Ieast=0,
>>>> OB_Iwest=0,
>>>> OB_Jnorth(16:28)=13*41,
>>>> OB_Jsouth(16:28)=13*3,
>>>> useOBCSprescribe = .TRUE.,
>>> These files should be found, if they are in the same directory where you
>> run your model. They should each contain (according to you dimensions and
>> time parameters) for 100 timesteps 100 fields of dimension (nx,nz). For
>> anything above 1000 timesteps, they should have 1000 fields (because after
>> the 1000ths record, the model starts from the beginning again, according to
>> you externForcingCycle)
>>>> OBNvFile = 'OBzonalV.bin',
>>>> OBSvFile = 'OBzonalV.bin',
>>>> OBNuFile = 'OBmeridU.bin',
>>>> OBSuFile = 'OBmeridU.bin?,
>>> # same as before this will give you a lot of output. You may want to
>> comment out this line, becasue OBCS_monitorFreq = monitorFreq by default
>>>> OBCS_monitorFreq=1200.00,
>>>> OBCS_monSelect = 1,
>>>> &
>>>>
>>>> &OBCS_PARM02
>>>> &
>>>> are you using latest code (some of the flags in the build-option look
>> very outdated ?)?
>>>> Yes, it is the latest code (version MITgcm_c67k). About the flags in
>> my build version, I did not make my own one. I used one that I found in our
>> research group.
>>>>
>>>> Kind regards,
>>>>
>>>> Estanislao
>>>>
>>>
>>>
>>>
>>> ------------------------------
>>>
>>> Message: 2
>>> Date: Thu, 22 Aug 2019 09:33:18 -0400
>>> From: Jean-Michel Campin <jmc at mit.edu>
>>> To: mitgcm-support at mitgcm.org
>>> Subject: Re: [MITgcm-support] Reading errors
>>> Message-ID: <20190822133318.GA13562 at ocean.mit.edu>
>>> Content-Type: text/plain; charset=us-ascii
>>>
>>> Hi Estanis,
>>>
>>> Just a small adjustment:
>>> the standard optfile for intel compiler (version 11 and newer) is:
>>> linux_amd64_ifort11
>>> in MITgcm/tools/build_options
>>> The optfile "linux_amd64_ifort" is for older version (10 and older).
>>>
>>> However, if you are compiling with intel MPI (recent version of the
>> compiler),
>>> then you need to use: linux_amd64_ifort+impi
>>>
>>> Cheers,
>>> Jean-Michel
>>>
>>> On Thu, Aug 22, 2019 at 01:10:55PM +0200, Martin Losch wrote:
>>>> Hi Estanis,
>>>>
>>>> thanks for the details. This is what I would do:
>>>>
>>>> - At the compile level use a standard build options file, with an
>> intel compiler on a linux system I would start with
>> MITgcm/tools/build_options/linux_amd64_ifort, or linux_ia64_ifort
>> (depending on the output of uname -a, in fact, genmake2 is probably able to
>> pick the correct file if you don???t specify it), and since your domain is
>> small I would first try without MPI, ie. like this:
>>>>
>>>> ${somepath}/tools/genmake2 -of
>> ${somepath}/tools/build_options/linux_amd64_ifort -mods ../code
>>>> make CLEAN && make depend && make
>>>>
>>>> - With this non-MPI configuration I would try to run the model. First
>> with useOBCS=.FALSE. (just a few timesteps), and then with .TRUE.
>>>>
>>>> - once this works, you can recompile with MPI (if you really need it),
>> like this:
>>>>
>>>> ${somepath}/tools/genmake2 -of
>> ${somepath}/tools/build_options/linux_amd64_ifort -mods ../code -mpi
>>>> make CLEAN && make depend && make
>>>> (note that the extra flag ???-mpi" is enough)
>>>>
>>>> and check if you get the same. For further help, you should record the
>> potential error messages after each step.
>>>>
>>>> Martin
>>>>
>>>> PS. Some comments about your namelist below:
>>>>
>>>>> On 22. Aug 2019, at 12:39, Estanislao Gavilan Pascual-Ahuir <
>> dramauh at hotmail.com> wrote:
>>>>>
>>>>> Hi Martin ,
>>>>>
>>>>> Before anything thank you so much for your help. I will try to
>> answer all you questions.
>>>>>
>>>>> what is the platform, the compiler?
>>>>> The platform in linux 2.6.32-431.TH.x86_64 GNU/Linux. Red Hat
>> Enterprise Linux Server release 6.5. I am using intel compilers wrapped
>> them in mpi. The version of the compiler is 14.0.2
>>>>> details of the configuration (content of code-directory and namelist
>> files)
>>>>> I am running a simple simulation with open boundaries. I load the
>> packages gfd, obcs, mnc and diagnostics using the packages.config. The
>> frequency of the open boundaries is stated in the data file. This is the
>> data file
>>>>> Model parameters
>>>>> # Continuous equation parameters
>>>>> &PARM01
>>>>> tRef=23.,23.,
>>>>> sRef=35.,35.,
>>>>> selectCoriMap=4,
>>>>> viscAh=4.E2,
>>>> with your grid choice (sphericalPolarGrid), the coriolis parameter is
>> computed and these values are not used.
>>>>> f0=1.E-4,
>>>>> beta=1.E-11,
>>>>> rhoNil=1000.,
>>>>> gBaro=9.81,
>>>>> rigidLid=.FALSE.,
>>>>> implicitFreeSurface=.TRUE.,
>>>>> # momAdvection=.FALSE.,
>>>>> tempStepping=.FALSE.,
>>>>> saltStepping=.FALSE.,
>>>>> &
>>>>>
>>>>> # Elliptic solver parameters
>>>>> &PARM02
>>>>> cg2dTargetResidual=1.E-7,
>>>>> cg2dMaxIters=1000,
>>>>> &
>>>>>
>>>>> # Time stepping parameters
>>>>> &PARM03
>>>>> nIter0=0,
>>>>> nTimeSteps=100,
>>>>> deltaT=1200.0,
>>>>> pChkptFreq=31104000.0,
>>>>> chkptFreq=15552000.0,
>>>>> dumpFreq=15552000.0,
>>>> # this will give you monitor output every timestep (which is what you
>> want while debugging), later I would set it to something like 20-50 * deltaT
>>>>> monitorFreq=1200.,
>>>>> monitorSelect=2,
>>>>> periodicExternalForcing=.TRUE.,
>>>> # this means that you will read data each time step. Is that what you
>> want?
>>>>> externForcingPeriod= 1200.,
>>>> # with your choice of externForcingPeriod, this requires that you have
>> 1000. records in the file(s)
>>>>> externForcingCycle = 12000000.,
>>>>> &
>>>>> # Gridding parameters
>>>>> &PARM04
>>>>> usingSphericalPolarGrid=.TRUE.,
>>>> # alternatively you can say dxSpacing = 1., dySpacing = 1.,
>>>>> delX=43*1.,
>>>>> delY=43*1.,
>>>>> xgOrigin=-21.,
>>>>> ygOrigin=-21.,
>>>>> delR=2*500.,
>>>>> &
>>>>>
>>>>> # Input datasets
>>>>> &PARM05
>>>>> bathyFile='bathy_cir.bin'
>>>>> meridWindFile=,
>>>>> &
>>>>>
>>>>> This is the data.obcs
>>>>>
>>>>> # Open-boundaries
>>>>> &OBCS_PARM01
>>>>> OBCSfixTopo=.FALSE.,
>>>> # if I understand the configuration correctly, you have a zonally
>> reentrant channel with wall in the north and the south (python notation:
>> bathy[0+2,:] = 0, and bathy[ny-1,:] = 0, except where you have the open
>> boundaries)? you could actually save two grid rows (have 40 instead of 43
>> point in j-direction and set bathy[0,:]=0, bathy[ny,:]=0)
>>>>> OB_Ieast=0,
>>>>> OB_Iwest=0,
>>>>> OB_Jnorth(16:28)=13*41,
>>>>> OB_Jsouth(16:28)=13*3,
>>>>> useOBCSprescribe = .TRUE.,
>>>> These files should be found, if they are in the same directory where
>> you run your model. They should each contain (according to you dimensions
>> and time parameters) for 100 timesteps 100 fields of dimension (nx,nz). For
>> anything above 1000 timesteps, they should have 1000 fields (because after
>> the 1000ths record, the model starts from the beginning again, according to
>> you externForcingCycle)
>>>>> OBNvFile = 'OBzonalV.bin',
>>>>> OBSvFile = 'OBzonalV.bin',
>>>>> OBNuFile = 'OBmeridU.bin',
>>>>> OBSuFile = 'OBmeridU.bin???,
>>>> # same as before this will give you a lot of output. You may want to
>> comment out this line, becasue OBCS_monitorFreq = monitorFreq by default
>>>>> OBCS_monitorFreq=1200.00,
>>>>> OBCS_monSelect = 1,
>>>>> &
>>>>>
>>>>> &OBCS_PARM02
>>>>> &
>>>>> are you using latest code (some of the flags in the build-option
>> look very outdated ?)?
>>>>> Yes, it is the latest code (version MITgcm_c67k). About the flags in
>> my build version, I did not make my own one. I used one that I found in our
>> research group.
>>>>>
>>>>> Kind regards,
>>>>>
>>>>> Estanislao
>>>>>
>>>>
>>>> _______________________________________________
>>>> MITgcm-support mailing list
>>>> MITgcm-support at mitgcm.org
>>>> http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support
>>>
>>>
>>> ------------------------------
>>>
>>> Subject: Digest Footer
>>>
>>> _______________________________________________
>>> MITgcm-support mailing list
>>> MITgcm-support at mitgcm.org
>>> http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support
>>>
>>>
>>> ------------------------------
>>>
>>> End of MITgcm-support Digest, Vol 194, Issue 12
>>> ***********************************************
>>> _______________________________________________
>>> MITgcm-support mailing list
>>> MITgcm-support at mitgcm.org
>>> http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support
>>
>>
>>
>> ------------------------------
>>
>> Subject: Digest Footer
>>
>> _______________________________________________
>> MITgcm-support mailing list
>> MITgcm-support at mitgcm.org
>> http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support
>>
>>
>> ------------------------------
>>
>> End of MITgcm-support Digest, Vol 194, Issue 14
>> ***********************************************
>> _______________________________________________
>> MITgcm-support mailing list
>> MITgcm-support at mitgcm.org
>> http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://mailman.mitgcm.org/pipermail/mitgcm-support/attachments/20190824/29af656a/attachment.html>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mailman.mitgcm.org/mailman/listinfo/mitgcm-support
>
>
> ------------------------------
>
> End of MITgcm-support Digest, Vol 194, Issue 17
> ***********************************************
More information about the MITgcm-support
mailing list