[MITgcm-support] Hello
smaeilpour
saeid_gal at yahoo.com
Thu Nov 10 14:24:59 EST 2016
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
More information about the MITgcm-support
mailing list