[MITgcm-support] Hello

smaeilpour saeid_gal at yahoo.com
Fri Nov 11 12:32:31 EST 2016


Hi Martin,
Thank you so much for your help, I acted exactly like your advice but after running a test case again error.,,
this time the errors were as fallows:

make [1]: *** [all_proc_dio.o]  Error 1

make: *** [fwd_exe_target]  Error 2
 
 How do i fix these errors? any idea? I am grateful for your guidance

Best
saeid




--------------------------------------------
On Fri, 11/11/16, Martin Losch <martin.losch at awi.de> wrote:

 Subject: Re: [MITgcm-support] Hello
 To: "MITgcm Support" <mitgcm-support at mitgcm.org>
 Date: Friday, November 11, 2016, 3:48 AM
 
 First of all, you shouldn’t use
 "linux_amd64_gfortran+mpi_generic”. This mean that you
 either use very old code, that we cannot really help you
 with or you that you have copied it from the
 “tools/build_options/unsupported” directory, where again
 the directory name implies that we don’t support these
 files anymore. 
 
 I suggest you use recent code with
 -of ../../../tools/build_options/linux_amd64_gfortran
 if you want to use gfortran. If you want to use MPI, then
 use the option -mpi and before you run genmake2 again, set
 the environment variable MPI_INC_DIR to point to you
 mpi-include directory (the one that contains “mpif.h”),
 ask your system admin where that is.
 
 Martin
 
 
 
 > On 10 Nov 2016, at 20:24, smaeilpour <saeid_gal at yahoo.com>
 wrote:
 > 
 > My command as:
 > 
 > ../../../tools/genmake2 -mods=../code -mpi
 -of=../../../tools/build_options/linux_amd64_gfortran+mpi_generic
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > --------------------------------------------
 > On Thu, 11/10/16, Matthew Mazloff <mmazloff at ucsd.edu>
 wrote:
 > 
 > Subject: Re: [MITgcm-support] Hello
 > To: mitgcm-support at mitgcm.org
 > Date: Thursday, November 10, 2016, 10:36 PM
 > 
 > What is the command you
 > compile with
 > 
 > do you give a
 > 
 > -of 
 > option? This should
 > point to a file that has paths in it, and these paths
 should
 > point to the compiler you are using. 
 > typing
 > which ifort 
 > will tell you the path to the compiler in your
 > environment
 > 
 > mpif.h is for
 > parallel computing — are you trying to run
 multi-core?
 > 
 > Matt
 > 
 > 
 > 
 >> On Nov
 > 10, 2016, at 10:55 AM, smaeilpour <saeid_gal at yahoo.com>
 > wrote:
 >> 
 >> Very
 > thanks for your help,
 >> 
 >> could you tell me how to changes in my
 > paths? 
 >> 
 >> 
 >> 
 > --------------------------------------------
 >> On Thu, 11/10/16, Matthew Mazloff <mmazloff at ucsd.edu>
 > wrote:
 >> 
 >> Subject:
 > Re: [MITgcm-support] Hello
 >> To: mitgcm-support at mitgcm.org
 >> Date: Thursday, November 10, 2016, 9:28
 > PM
 >> 
 >> This is likely
 > a platform
 >> issue. Most likely your path
 > to your ifort compiler is
 >> wrong.  
 >> 
 >> You need to
 >> change your optfile to point to the
 > correct path. If all was
 >> working fine
 > and now it is not then it is likely that
 >> someone updated the fortran compilers on
 > your machine and
 >> the paths have
 > changed.
 >> 
 >> Clean
 > out your build folder. Fix your paths.
 >> 
 > Try again
 >> 
 >> Hope
 > this
 >> helps
 >> 
 >> -Matt
 >> 
 >> 
 >> 
 >>> On Nov 10, 2016, at 9:39 AM,
 > smaeilpour
 >> <saeid_gal at yahoo.com>
 >> wrote:
 >>> 
 >>> Hi, 
 >>> 
 >>> I have been having
 >> some problem compiling my code today,
 > after doing 
 >>> 
 >>>> make depend
 >>> 
 >>> I get the
 > following
 >> error
 >>> 
 >>> 
 >> 
 > ../../../tools/cyrus-imapd-makedepend/makedepend:
 warning
 >> :
 >>> 
 > mdsio_readfield.F (reading SUPPORT.h,
 >> 
 > line 179): cannot find include
 >>> 
 > file
 >> "mpif.h"  
 >>> 
 >>>        
 >     not in mpif.h
 >>>          
 >   not in mpif.h
 >>>            
 > not in   
 >> 
 > opt/ifort/8.0.044/include/mpif.h
 >>> 
 > 
 >> 
 > ../../../tools/f90makedepend>>makefile
 >>> 
 >>> 
 >>> and as a result I cannot compile
 > the
 >> code.
 >>> I am
 > sure i have overlooked
 >> something quite
 > simple.
 >>> 
 >>> 
 > any Idea
 >>> 
 >>> 
 > thanks a lot in advance
 >>> saeid
 >>> 
 >>> 
 >>> 
 >>> 
 >>> 
 >>> 
 >>> 
 >> 
 > --------------------------------------------
 >>> 
 >>> 
 >>> 
 >> 
 >
 ----------------------------------------------------------------------------------------
 >>> On Thu, 11/10/16, Jean-Michel
 > Campin
 >> <jmc at mit.edu> wrote:
 >>> 
 >>> Subject:
 > Re:
 >> [MITgcm-support] river runoff
 >>> To: mitgcm-support at mitgcm.org
 >>> Date: Thursday, November 10, 2016,
 > 10:42
 >> AM
 >>> 
 >>> Hi,
 >>> 
 >>> There are few
 >> 
 > available options for including
 >>> 
 >> run-off:
 >>> 
 >>> 1) the
 >> most
 >>> commonly used is to include just
 >> in the surface level,
 >>>    as part of
 >> surface forcing (substracted to EmP
 >>> 
 >> into EmPmR).
 >>>    Obviously this
 > approach
 >> is not
 >>> great for deep estuary with
 >> high
 >>>    vertical
 >>> 
 >> resolution
 > (small dz).
 >>>    And the
 > effect
 >> on
 >>> 
 > sea-level is accounted for with
 >>> 
 > useRealFreshWaterFlux=.TRUE.,
 >>>    and in a
 >>> consistent
 >> way
 > for any tracers when Non-Lin Freee-surface
 >>> is
 >>>    used.
 >>>    In this case, the
 >>> 
 >> run-off can be
 > provide as part of EmPmR or
 >>> 
 >>> separately (e.g.,
 >> 
 > using pkg/exf), but only the run-off that
 >>> fall
 >>>    on ocean grid
 >> cell (wet-cell) will be
 >>> considered.
 >>> 
 > 
 >>> 2) If you want
 >>> to address the issue of deep
 > estuaries,
 >> you can 
 >>>     try to prescribe
 >> a 3-D run-off input (file:
 >>> addMassFile
 >> 
 > loaded into 
 >>>     model 2-D
 >> array
 >>> 
 > "addMass") using
 >> 
 > selectAddFluid=1.
 >>>     This
 >> requires to compile with #define
 >>> 
 >> 
 > ALLOW_ADDFLUID
 >>> 
 >>>     Note that
 >>> the current code does not provide
 > an
 >> option to prescribe
 >>>     time
 >> 
 > dependent "addMass" inflow
 >>> 
 >> (but should not
 > be difficult to add).
 >>> 
 >> 
 >>> 3) And the last
 > option, as described
 >> by Andrea,
 >>> is to use OBCS. This enable
 >> 
 >>>     to
 > account,
 >>> in the momentum budget,
 > for the speed of
 >> the incoming
 >>> run-off.
 >>>    
 > Probably useful at very high
 >> to
 >>> high resolution (bot horizontal and
 >> vertical)
 >>>    
 > but may be not
 >> so important at lower
 >>> resolution.
 >>> 
 > 
 >>> Cheers,
 >>> 
 > Jean-Michel
 >>> 
 >>> On
 >>> Wed, Nov
 > 09, 2016
 >> at 08:31:34AM +0100, Andrea
 > Cimatoribus
 >>> 
 >> 
 > wrote:
 >>>> Certainly not the
 > most
 >> expert
 >>> 
 > around here, but I have been
 >> dealing
 >>>> 
 >>> with
 >> this lately, so I can try an answer.
 >>>> 
 >>>> The
 > neatest
 >> way to
 >>> 
 > do it is with obcs package, that
 >> is,
 > the open
 >>>> boundary package.
 > In
 >> data.obcs you can
 >>> define the (vertical)
 >> grid
 >>>> faces
 >>> 
 >> through which
 > you want to apply the discharge (see
 >>> manual).
 >>>> 
 > Using
 >> the correct grid metric,
 >>> you can set
 >> the
 > discharge velocity to
 >>>> 
 >>> match the total volume discharge (and
 > you
 >> can easily check
 >>> if you
 >>>> 
 > are doing it right using the
 >>> 
 > diagnostic output). The simplest way to
 >>>> 
 >>> impose
 > a
 >> time-variable discharge and
 > temperature is via the
 >>> exf
 >>>> package, in a
 >> 
 > new namelist which is
 >>> provided by
 > the
 >> OBCS package,
 >>>> something
 >>> 
 > along these lines:
 >>>>    
 >>> 
 >> 
 > &EXF_NML_OBCS
 >>>> # OBCS
 >> prescribe
 >>>>  
 >   obcsEstartdate1   =
 >>> 
 > 20080101,
 >>>>    
 >>> obcsEstartdate2   =
 > 010000,
 >>>>    
 > obcsEperiod   
 >>     =
 >>> 3600.,
 >>>>  
 >   obcsWstartdate1   =
 >>> 
 > 20080101,
 >>>>    
 >>> obcsWstartdate2   =
 > 010000,
 >>>>    
 > obcsWperiod   
 >>     =
 >>> 3600.,
 >>>>  
 >   &
 >>>> As
 >>> far as I
 >> 
 > understand, the temperature of the discharge must
 >>> span
 >>>> 
 > exactly the
 >> same time interval and
 >>> have the same
 >> 
 > periodicity as the
 >>>> 
 >>> velocity.
 >>>> 
 > The
 >> file names containing the
 >>> data are
 >> defined
 > in the data.obcs
 >>>> 
 >>> (again, see manual).
 >>>> 
 >>>> Hope
 > this
 >> helps, best,
 >>>> 
 >>>> 
 > Andrea
 >>> 
 >> 
 > Cimatoribus
 >>>> postdoctoral
 >> researcher
 >>>> 
 > EPFL ENAC IIE ECOL
 >>>> https://people.epfl.ch/andrea.cimatoribus
 >>>> 
 >>>> On
 > 09/11/16
 >> 03:26,
 >>> ????????? wrote:
 >>>>> Hi
 >>>>> 
 >> 
 >>>>> I am using
 >>> mitgcm to simulate SST variation in
 >> coastal area with
 >>> 
 > large
 >>>>> runoff. Does anyone
 > tell me
 >>> how to set up the river?
 > How mitgcm
 >> deal
 >>>>> with river mouth?
 >>>> 
 >>>> 
 >>>>> I've known that the
 > runoff
 >>> should be added to the
 > freshwater flux
 >> EmPmR,
 >>>>> but how to represent the
 >> effect of a
 >>> river
 > by gridded runoff
 >> data is not
 >>>> 
 >>>> 
 > clear to me (should the river grid
 >> 
 > point be contacted
 >>> with ocean
 >>>>> interior or
 >>> 
 >> boundary?).
 >>>>> 
 >>>> 
 > 
 >>>> It seems
 >> 
 > that the test cases in mitgcm do not provide
 >>> enough river
 >>>>> 
 >> 
 > information.
 >>>>> 
 >>>>> I'd
 >>> 
 >> appreciate any
 > help.
 >>>>> 
 >>>>> 
 >>>> 
 > 
 >>>> ------------------
 >>>>> Best
 >>> 
 > 
 >> regards
 >>>>> 
 >>>> 
 > 
 >>>> Yu-Kun Qian
 >> (?????????)
 >>>>> Center
 >>> for Monsoon and Environment
 > Research
 >>>> 
 >>>> Department
 >> of
 > Atmospheric Sciences
 >>>> 
 >>>> School of Environmental Science
 > and
 >> Engineering
 >>>>> Sun Yat-sen
 >> University
 >>>>> No. 135 Xingang West
 >> Road, Haizhu
 >>> 
 > District
 >>>>> Guangzhou, 510275,
 > P.R.
 >>> China
 >>>>> Tel;
 >> 
 > 020-84115227
 >>>>> Email: qianyk at mail3.sysu.edu.cn
 >>> <mailto:qianyk at mail2.sysu.edu.cn>
 >>>>> 
 >>>>> 
 >>>>> 
 >>>>> 
 >>>> 
 > 
 >>>> 
 >> 
 > _______________________________________________
 >>>>> 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
 >>> 
 >> 
 >>> 
 >> 
 > _______________________________________________
 >>> 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
 >> 
 >> 
 >> 
 > _______________________________________________
 >> 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
 > 
 > 
 > _______________________________________________
 > 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
 
 
 _______________________________________________
 MITgcm-support mailing list
 MITgcm-support at mitgcm.org
 http://mitgcm.org/mailman/listinfo/mitgcm-support
 



More information about the MITgcm-support mailing list