[MITgcm-support] Re: MITgcm-support Digest, Vol 59, Issue 25
vinod mishra
vkmishra2005 at gmail.com
Tue May 27 07:37:10 EDT 2008
sir
Thanks for valuable suggetion
now after executing the command "make" the following errors are generated.
ld32: INFO 136: In order to increase performance, the linker has decided
to pad
individual arrays within common block dynvars_cd_.
Please see -OPT:reorg_common in the fortran man pages for
details.
ld32: INFO 136: In order to increase performance, the linker has decided
to pad
individual arrays within common block grid_r_.
Please see -OPT:reorg_common in the fortran man pages for
details.
ld32: INFO 136: In order to increase performance, the linker has decided
to pad
individual arrays within common block surf_fixed_.
Please see -OPT:reorg_common in the fortran man pages for
details.
ld32: INFO 136: In order to increase performance, the linker has decided
to pad
individual arrays within common block exact_eta_local_.
Please see -OPT:reorg_common in the fortran man pages for
details.
ld32: INFO 136: In order to increase performance, the linker has decided
to pad
individual arrays within common block dynvars_r_.
Please see -OPT:reorg_common in the fortran man pages for
details.
ld32: INFO 136: In order to increase performance, the linker has decided
to pad
individual arrays within common block dynvars_diag_.
Please see -OPT:reorg_common in the fortran man pages for
details.
ld32: INFO 136: In order to increase performance, the linker has decided
to pad
individual arrays within common block surf_index_.
Please see -OPT:reorg_common in the fortran man pages for
details.
ld32: INFO 136: In order to increase performance, the linker has decided
to pad
individual arrays within common block tdfields_.
Please see -OPT:reorg_common in the fortran man pages for
details.
ld32: INFO 136: In order to increase performance, the linker has decided
to pad
individual arrays within common block surface_forcing_.
Please see -OPT:reorg_common in the fortran man pages for
details.
ld32: INFO 136: In order to increase performance, the linker has decided
to pad
individual arrays within common block exch_r_.
Please see -OPT:reorg_common in the fortran man pages for
details.
ld32: INFO 136: In order to increase performance, the linker has decided
to pad
individual arrays within common block cg2d_i_r_.
Please see -OPT:reorg_common in the fortran man pages for
details
ld32: INFO 136: In order to increase performance, the linker has decided
to pad
individual arrays within common block cg2d_i_wk_r_.
Please see -OPT:reorg_common in the fortran man pages for
details.
ld32: INFO 136: In order to increase performance, the linker has decided
to pad
individual arrays within common block sfp_common_r8_.
Please see -OPT:reorg_common in the fortran man pages for
details.
ld32: ERROR 33 : Unresolved text symbol "timenow_" -- 1st referenced by
timers
.o.
Use linker option -v to see when and which objects, archives and
dsos ar
e loaded.
ld32: INFO 152: Output file removed because of error.
*** Error code 2 (bu21)
kindly give the suggetion for removing the error
vinod mishra
Allahabad, UP,INDIA
On 5/26/08, mitgcm-support-request at mitgcm.org <
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. request fo support (vinod mishra)
> 2. Re: request fo support (Martin Losch)
> 3. Re: Re: MITgcm files (Renske Gelderloos)
> 4. Re: Re: MITgcm files (Martin Losch)
> 5. Re: Questions on curvilinear grid (Luca Liberti)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 26 May 2008 14:55:16 +0530
> From: "vinod mishra" <vkmishra2005 at gmail.com>
> Subject: [MITgcm-support] request fo support
> To: MITgcm-support at mitgcm.org
> Message-ID:
> <a5c120090805260225v57f745e2v5b05a7fabc2208b6 at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> sir
> my self working on following system
> "IRIX Release 6.5 IP35 IRIS
> Copyright 1987-2006 Silicon Graphics,"
> but our system send the following error message after running the
> command "../../../tools/genmake2
> -mods=../code ".
> *Error*
>
> IRIS 4% sh ./genmake2 -mods=../code
>
> GENMAKE :
>
> A program for GENerating MAKEfiles for the MITgcm project. For a
> quick list of options, use "genmake -h" or for more detail see:
>
> http://mitgcm.org/devel_HOWTO/
>
> === Processing options files and arguments ===
> getting local config information: none found
> Warning: ROOTDIR was not specified but there appears to be a copy of
> MITgcm
> at
> ".." so we'll try it.
> getting OPTFILE information:
> Warning: no OPTFILE specified so we'll look for possible settings
>
> === Searching for possible settings for OPTFILE ===
> The platform appears to be: irix64_ip35
> The possible C compilers found in your path are:
> c89 cc c99
> Setting C compiler to: c89
> The possible FORTRAN compilers found in your path are:
> f77 f90
> Setting OPTFILE to: ../tools/build_options/irix64_ip35_f77
> using OPTFILE="../tools/build_options/irix64_ip35_f77"
> getting AD_OPTFILE information:
> using AD_OPTFILE="../tools/adjoint_options/adjoint_default"
>
> === Checking system libraries ===
> Do we have the system() command using f77... yes
> Do we have the fdate() command using f77... yes
> Do we have the etime() command using f77... yes
> Can we call simple C routines (here, "cloc()") using f77... no
> Can we unlimit the stack size using f77... no
> Can we register a signal handler using f77... no
> Can we use stat() through C calls... no
> Can we create NetCDF-enabled binaries... no
>
> === Setting defaults ===
> Adding MODS directories:
> Error: MODS directory "../code" not found!
>
> therefore you are requested kindly suggest me how i make new optfile ? &
> (or) how i proceed in next step.
>
> with regard
>
>
> V K MISHRA
> Allahabad ,UP ,INDIA
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://forge.csail.mit.edu/pipermail/mitgcm-support/attachments/20080526/d851851b/attachment-0001.html
>
> ------------------------------
>
> Message: 2
> Date: Mon, 26 May 2008 11:32:51 +0200
> From: Martin Losch <Martin.Losch at awi.de>
> Subject: Re: [MITgcm-support] request fo support
> To: mitgcm-support at mitgcm.org
> Message-ID: <35B92005-E6F5-4372-BC04-16B7264B4C6F at awi.de>
> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
>
> Hi,
>
> you are using the default opt-file for your system:
> MITgcm/tools/build_options/irix64_ip35_f77
> If you are unhappy about some of the flags, you can easily change
> them in the file and rerun genmake2 (make makefile), or create a new
> one based on the default file.
>
> But your problem is clearly something else as the error message
> describes:
> > === Setting defaults ===
> > Adding MODS directories:
> > Error: MODS directory "../code" not found!
>
> Here's my translation: you don't have "../code" directory, that you
> specify on the command line when invoking genmake2 ('-mods ../code').
> This directory should at least include a "SIZE.h" that is specific to
> your experiment.
>
> Martin
>
> On 26 May 2008, at 11:25, vinod mishra wrote:
>
> >
> > sir
> > my self working on following system
> > "IRIX Release 6.5 IP35 IRIS
> > Copyright 1987-2006 Silicon Graphics,"
> > but our system send the following error message after running the
> > command "../../../tools/genmake2 -mods=../code ".
> > Error
> > IRIS 4% sh ./genmake2 -mods=../code
> >
> > GENMAKE :
> >
> > A program for GENerating MAKEfiles for the MITgcm project. For a
> > quick list of options, use "genmake -h" or for more detail see:
> >
> > http://mitgcm.org/devel_HOWTO/
> >
> > === Processing options files and arguments ===
> > getting local config information: none found
> > Warning: ROOTDIR was not specified but there appears to be a copy
> > of MITgcm at
> > ".." so we'll try it.
> > getting OPTFILE information:
> > Warning: no OPTFILE specified so we'll look for possible settings
> >
> > === Searching for possible settings for OPTFILE ===
> > The platform appears to be: irix64_ip35
> > The possible C compilers found in your path are:
> > c89 cc c99
> > Setting C compiler to: c89
> > The possible FORTRAN compilers found in your path are:
> > f77 f90
> > Setting OPTFILE to: ../tools/build_options/irix64_ip35_f77
> > using OPTFILE="../tools/build_options/irix64_ip35_f77"
> > getting AD_OPTFILE information:
> > using AD_OPTFILE="../tools/adjoint_options/adjoint_default"
> >
> > === Checking system libraries ===
> > Do we have the system() command using f77... yes
> > Do we have the fdate() command using f77... yes
> > Do we have the etime() command using f77... yes
> > Can we call simple C routines (here, "cloc()") using f77... no
> > Can we unlimit the stack size using f77... no
> > Can we register a signal handler using f77... no
> > Can we use stat() through C calls... no
> > Can we create NetCDF-enabled binaries... no
> >
> > === Setting defaults ===
> > Adding MODS directories:
> > Error: MODS directory "../code" not found!
> >
> > therefore you are requested kindly suggest me how i make new
> > optfile ? & (or) how i proceed in next step.
> >
> > with regard
> >
> >
> >
> > V K MISHRA
> > Allahabad ,UP ,INDIA
> >
> >
> > _______________________________________________
> > MITgcm-support mailing list
> > MITgcm-support at mitgcm.org
> > http://mitgcm.org/mailman/listinfo/mitgcm-support
>
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 26 May 2008 13:27:01 +0000
> From: Renske Gelderloos <gelderlo at knmi.nl>
> Subject: Re: [MITgcm-support] Re: MITgcm files
> To: mitgcm-support at mitgcm.org
> Message-ID: <483ABAA5.90004 at knmi.nl>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hi Martin,
>
> Thanks for the advice. The part about the overlap in SIZE.h I don't
> really understand though. Isn't that the amount of grid cells that
> overlap between different tiles? So if you would use only one tile, it
> doesn't make much sense to me to prescribe overlap. Or is it not allowed
> to use only one tile? Furthermore, on my computer the model crashes with
> nonzero overlap.. ("solution is heading out of bounds (...),
> mon_solution: stopping calculation, mon_solution: stopped due to extreme
> values of solution"). So what is the idea behind the tiles and the overlap?
>
> Renske
>
> Martin Losch wrote:
> > Hi Renske,
> >
> > I am returning your files with my modficiations, but all of these are
> > related to general stability of the code. I could not reproduce the
> > problem that you described, namely that a non-zero heat flux does not
> > change the surface temperature. For testing, try a non-uniform heat
> > flux that introduces a horizontal pressure gradient and immediate
> > flow. With a uniform heat flux and uniform initial conditions (in the
> > horizontal) and a stable water column you should never get any flow.
> > (as a side remark: I did get non-zero velocities after the second
> > timestep, which should not happen, but that's not your problem. Is
> > that a problem with step topography, and vertical diffusion? very
> > worrying).
> >
> > a couple of problems:
> > SIZE.h: you set the overlaps to 0, that will probably not work ( and
> > did not work for me, the model blows up immediately, I am surprised
> > that we don't have a catch for that, maybe it is allowed?). I changed
> > them to 4 (but 2 should be enough).
> >
> > data:
> > - deltaT = 86400 is much too large a time step and will also lead to
> > the model blowing up immediately (once there is motion), but you
> > probably knew that
> > - I put sref = 15*0.0, (although some compiler will probably take
> > sref=0.0 as well)
> > - diffKzT = 20., is awfully large if implicitVerticalDiffusion is not
> > turned on (default). I set it to 1.e-5 for now.
> >
> > topography:
> > - I usually try to set a minimum depth which should be at least the
> > thickness of the top-most grid cell, can be set in "data" by hFacMinDz
> >
> >
> >
> >
> > On 23 May 2008, at 17:50, Gelderloos, Renske (KNMI) wrote:
> >
> >> Dear Martin,
> >>
> >> Here are all the files you requested. I would really appreciate it if
> >> you would want to take a look at it, I'm pretty stuck... Hope you can
> >> help me!
> >>
> >> Renske
> >>
> >> ________________________________
> >>
> >> From: Gelderloos, Renske (KNMI)
> >> Sent: Fri 5/23/2008 2:09 PM
> >> To: Gelderloos, Renske (KNMI)
> >> Subject: MITgcm files
> >>
> >>
> >>
> >>
> <data><data.mnc><data.pkg><eedata><Qnetuniform.bin><topogOBCmatlab.bin><packages.conf><SIZE.h><LabradorOBC.m><heatuniform.m>
> >>
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > MITgcm-support mailing list
> > MITgcm-support at mitgcm.org
> > http://mitgcm.org/mailman/listinfo/mitgcm-support
>
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 26 May 2008 15:49:13 +0200
> From: Martin Losch <Martin.Losch at awi.de>
> Subject: Re: [MITgcm-support] Re: MITgcm files
> To: mitgcm-support at mitgcm.org
> Message-ID: <D9C0D0C6-76DD-4989-A61E-0B07F963D340 at awi.de>
> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
>
> Renske,
>
> the model horizontal domain is (1:nx,1:ny), but if you want to
> evaluate horizontal gradients along the boundaries you need at least
> one more grid point to do so. (otherwised you'd have to include code
> such as "if (1<i<nx) do something in the interior, else do something
> different at the boundary"), the second grid point you need for
> second derivatives for the laplacian (harmonic) viscosity and
> diffusivity. Olx/y>2 are needed for special advection schemes, etc.
> So, yes the overlap ensures the exchange between tiles, but it's also
> necessary on only one tile in order to get the computational stencil
> along the domain boundaries right. Plus I don't know what happens
> with the "exchange" routines (which are always called regardless of
> domain decomposition, just to get potentially cyclic boundary
> conditions right) if they exchange stuff of length zero
>
> I am pretty sure that your model crashes because of CFL-violations:
> Either your time step is too large for u*deltaT/deltax < (1,1/2, ...)
> or your viscosity is too large for the time step. Try smaller
> timesteps, for your resolution of 7.5km I recommend something like
> deltaT = 600s for a start.
>
> Martin
>
> On 26 May 2008, at 15:27, Renske Gelderloos wrote:
>
> > Hi Martin,
> >
> > Thanks for the advice. The part about the overlap in SIZE.h I
> > don't really understand though. Isn't that the amount of grid
> > cells that overlap between different tiles? So if you would use
> > only one tile, it doesn't make much sense to me to prescribe
> > overlap. Or is it not allowed to use only one tile? Furthermore, on
> > my computer the model crashes with nonzero overlap.. ("solution is
> > heading out of bounds (...), mon_solution: stopping calculation,
> > mon_solution: stopped due to extreme values of solution"). So what
> > is the idea behind the tiles and the overlap?
> >
> > Renske
> >
> > Martin Losch wrote:
> >> Hi Renske,
> >>
> >> I am returning your files with my modficiations, but all of these
> >> are related to general stability of the code. I could not
> >> reproduce the problem that you described, namely that a non-zero
> >> heat flux does not change the surface temperature. For testing,
> >> try a non-uniform heat flux that introduces a horizontal pressure
> >> gradient and immediate flow. With a uniform heat flux and uniform
> >> initial conditions (in the horizontal) and a stable water column
> >> you should never get any flow. (as a side remark: I did get non-
> >> zero velocities after the second timestep, which should not
> >> happen, but that's not your problem. Is that a problem with step
> >> topography, and vertical diffusion? very worrying).
> >>
> >> a couple of problems:
> >> SIZE.h: you set the overlaps to 0, that will probably not work
> >> ( and did not work for me, the model blows up immediately, I am
> >> surprised that we don't have a catch for that, maybe it is
> >> allowed?). I changed them to 4 (but 2 should be enough).
> >>
> >> data:
> >> - deltaT = 86400 is much too large a time step and will also lead
> >> to the model blowing up immediately (once there is motion), but
> >> you probably knew that
> >> - I put sref = 15*0.0, (although some compiler will probably take
> >> sref=0.0 as well)
> >> - diffKzT = 20., is awfully large if implicitVerticalDiffusion is
> >> not turned on (default). I set it to 1.e-5 for now.
> >>
> >> topography:
> >> - I usually try to set a minimum depth which should be at least
> >> the thickness of the top-most grid cell, can be set in "data" by
> >> hFacMinDz
> >>
> >>
> >>
> >>
> >> On 23 May 2008, at 17:50, Gelderloos, Renske (KNMI) wrote:
> >>
> >>> Dear Martin,
> >>>
> >>> Here are all the files you requested. I would really appreciate
> >>> it if you would want to take a look at it, I'm pretty stuck...
> >>> Hope you can help me!
> >>>
> >>> Renske
> >>>
> >>> ________________________________
> >>>
> >>> From: Gelderloos, Renske (KNMI)
> >>> Sent: Fri 5/23/2008 2:09 PM
> >>> To: Gelderloos, Renske (KNMI)
> >>> Subject: MITgcm files
> >>>
> >>>
> >>>
> >>> <data><data.mnc><data.pkg><eedata><Qnetuniform.bin><topogOBCmatlab.b
> >>> in><packages.conf><SIZE.h><LabradorOBC.m><heatuniform.m>
> >> ---------------------------------------------------------------------
> >> ---
> >>
> >> _______________________________________________
> >> 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: 5
> Date: Mon, 26 May 2008 16:30:36 +0200
> From: Luca Liberti <luca.liberti at apat.it>
> Subject: [MITgcm-support] Re: Questions on curvilinear grid
> To: mitgcm-support at mitgcm.org
> Message-ID: <483AC98C.9020402 at apat.it>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Thank you Martin for the quick answer.
> Luca and Gianmaria
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: luca.liberti.vcf
> Type: text/x-vcard
> Size: 329 bytes
> Desc: not available
> Url :
> http://forge.csail.mit.edu/pipermail/mitgcm-support/attachments/20080526/2312a49d/luca.liberti-0001.vcf
>
> ------------------------------
>
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-support
>
>
> End of MITgcm-support Digest, Vol 59, Issue 25
> **********************************************
>
--
SUCCESS IS JOURNEY
V K MISHRA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mitgcm.org/pipermail/mitgcm-support/attachments/20080527/3bd041e9/attachment.htm>
More information about the MITgcm-support
mailing list