[MITgcm-support] (no subject)
kaveh Purkiani
kavehpurkiani at googlemail.com
Fri Oct 23 06:09:31 EDT 2015
Hi Liam and Matt,
Thank you very much for you suggestions.
Indeed, increasing the number of cores solved the problem.
regards,
Kaveh.
On Fri, Oct 23, 2015 at 11:38 AM, Liam Brannigan <
Liam.Brannigan at physics.ox.ac.uk> wrote:
> Hi Kaveh
>
> As Matt said, this is a sign that your compiler is getting worried about
> memory. I think that the mcmodel-medium approach needs to be taken when
> the memory demand gets over 2GB per core. Rather than doing the mcmodel
> approach, perhaps you can try alternative approaches:
>
> 1) use more cores so that the memory per core is less
> 2) check the configuration in DIAGNOSTICS_SIZE.h to make sure that you are
> not asking the memory to make space for more diagnostics than you will need.
>
> In my experience, the default amount of space demanded in
> DIAGNOSTICS_SIZE.h isn't that big, so the first option may be preferable.
> Indeed, there is probably a good reason why memory is restricted to a
> certain size per core, as performance is likely to suffer as this limit is
> approached.
>
> Liam
> ________________________________________
> From: mitgcm-support-request at mitgcm.org [mitgcm-support-request at mitgcm.org
> ]
> Sent: 23 October 2015 04:52
> To: mitgcm-support at mitgcm.org
> Subject: MITgcm-support Digest, Vol 148, Issue 13
>
> 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. (no subject) (kaveh Purkiani)
> 2. Re: (no subject) (Matthew Mazloff)
> 3. exch2 and autogenerated grids (llc, cs, etc.) (Ryan Abernathey)
> 4. Re: exch2 and autogenerated grids (llc, cs, etc.)
> (Jean-Michel Campin)
> 5. Re: exch2 and autogenerated grids (llc, cs, etc.)
> (Ryan Abernathey)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 22 Oct 2015 18:53:22 +0200
> From: kaveh Purkiani <kavehpurkiani at googlemail.com>
> To: mitgcm-support at mitgcm.org
> Subject: [MITgcm-support] (no subject)
> Message-ID:
> <CA+SSPLBmdPsS3JFQg80djPrvVUVJhT5oG0iW76JA=
> h09uyCnJA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi everybody,
>
> As soon as I add the diagnostics to package.conf, I'll get this error
> massage during the compilation:
>
> config_summary.o: In function `config_summary_':
> config_summary.f:(.text+0x45d0): relocation truncated to fit: R_X86_64_32S
> against symbol `parm_eos_nl_' defined in COMMON section in config_summary.o
> config_summary.f:(.text+0x45ed): relocation truncated to fit: R_X86_64_32S
> against symbol `parm_eos_nl_' defined in COMMON section in config_summary.o
> config_summary.f:(.text+0x4605): relocation truncated to fit: R_X86_64_32S
> against symbol `parm_eos_nl_' defined in COMMON section in config_summary.o
> config_summary.f:(.text+0x463f): relocation truncated to fit: R_X86_64_32S
> against symbol `parm_eos_nl_' defined in COMMON section in config_summary.o
>
>
> find_alpha.o: In function `find_beta_':
> find_alpha.f:(.text+0x9a): relocation truncated to fit: R_X86_64_PC32
> against symbol `parm_eos_lin_' defined in COMMON section in
> config_summary.o
> find_alpha.f:(.text+0x45b): relocation truncated to fit: R_X86_64_32S
> against symbol `parm_eos_nl_' defined in COMMON section in config_summary.o
> find_alpha.f:(.text+0x465): relocation truncated to fit: R_X86_64_32S
> against symbol `parm_eos_nl_' defined in COMMON section in config_summary.o
> find_alpha.f:(.text+0x572): relocation truncated to fit: R_X86_64_32S
> against symbol `parm_eos_nl_' defined in COMMON section in config_summary.o
> find_alpha.f:(.text+0x590): relocation truncated to fit: R_X86_64_32S
> against symbol `parm_eos_nl_' defined in COMMON section in config_summary.o
> find_alpha.f:(.text+0x5b0): relocation truncated to fit: R_X86_64_32S
> against symbol `parm_eos_nl_' defined in COMMON section in config_summary.o
> find_alpha.f:(.text+0x5bd): additional relocation overflows omitted from
> the output
> collect2: ld returned 1 exit status
> make[1]: *** [mitgcmuv] Error 1
> make[1]: Leaving directory `/work/kpurkiani/sediment'
> make: *** [fwd_exe_target] Error 2
>
>
> Inside the code nothing has been manipulated regarding the equation of
> state.
>
> Any suggestions are very much appreciated.
>
> regards,
>
> Kaveh.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://mitgcm.org/pipermail/mitgcm-support/attachments/20151022/243b9ec1/attachment-0001.htm
> >
>
> ------------------------------
>
> Message: 2
> Date: Thu, 22 Oct 2015 10:16:50 -0700
> From: Matthew Mazloff <mmazloff at ucsd.edu>
> To: <mitgcm-support at mitgcm.org>
> Subject: Re: [MITgcm-support] (no subject)
> Message-ID: <3F186537-CAFB-4199-AED2-0859A7BFEF46 at ucsd.edu>
> Content-Type: text/plain; charset=us-ascii
>
> Hello
>
> This just means your executable is getting large and the compiler is
> getting "worried".
>
> To override this use a compiler flag -- which will depend on your compiler
> -- but will be something like
>
> -mcmodel = medium
>
> This is not an MITgcm thing -- so googling it will return a lot of info
>
> Matt
>
>
>
>
>
> On Oct 22, 2015, at 9:53 AM, kaveh Purkiani <kavehpurkiani at googlemail.com>
> wrote:
>
> > Hi everybody,
> >
> > As soon as I add the diagnostics to package.conf, I'll get this error
> massage during the compilation:
> >
> > config_summary.o: In function `config_summary_':
> > config_summary.f:(.text+0x45d0): relocation truncated to fit:
> R_X86_64_32S against symbol `parm_eos_nl_' defined in COMMON section in
> config_summary.o
> > config_summary.f:(.text+0x45ed): relocation truncated to fit:
> R_X86_64_32S against symbol `parm_eos_nl_' defined in COMMON section in
> config_summary.o
> > config_summary.f:(.text+0x4605): relocation truncated to fit:
> R_X86_64_32S against symbol `parm_eos_nl_' defined in COMMON section in
> config_summary.o
> > config_summary.f:(.text+0x463f): relocation truncated to fit:
> R_X86_64_32S against symbol `parm_eos_nl_' defined in COMMON section in
> config_summary.o
> >
> >
> > find_alpha.o: In function `find_beta_':
> > find_alpha.f:(.text+0x9a): relocation truncated to fit: R_X86_64_PC32
> against symbol `parm_eos_lin_' defined in COMMON section in config_summary.o
> > find_alpha.f:(.text+0x45b): relocation truncated to fit: R_X86_64_32S
> against symbol `parm_eos_nl_' defined in COMMON section in config_summary.o
> > find_alpha.f:(.text+0x465): relocation truncated to fit: R_X86_64_32S
> against symbol `parm_eos_nl_' defined in COMMON section in config_summary.o
> > find_alpha.f:(.text+0x572): relocation truncated to fit: R_X86_64_32S
> against symbol `parm_eos_nl_' defined in COMMON section in config_summary.o
> > find_alpha.f:(.text+0x590): relocation truncated to fit: R_X86_64_32S
> against symbol `parm_eos_nl_' defined in COMMON section in config_summary.o
> > find_alpha.f:(.text+0x5b0): relocation truncated to fit: R_X86_64_32S
> against symbol `parm_eos_nl_' defined in COMMON section in config_summary.o
> > find_alpha.f:(.text+0x5bd): additional relocation overflows omitted from
> the output
> > collect2: ld returned 1 exit status
> > make[1]: *** [mitgcmuv] Error 1
> > make[1]: Leaving directory `/work/kpurkiani/sediment'
> > make: *** [fwd_exe_target] Error 2
> >
> >
> > Inside the code nothing has been manipulated regarding the equation of
> state.
> >
> > Any suggestions are very much appreciated.
> >
> > regards,
> >
> > Kaveh.
> > _______________________________________________
> > MITgcm-support mailing list
> > MITgcm-support at mitgcm.org
> > http://mitgcm.org/mailman/listinfo/mitgcm-support
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 22 Oct 2015 17:16:17 -0400
> From: Ryan Abernathey <ryan.abernathey at gmail.com>
> To: "mitgcm-support at mitgcm.org" <mitgcm-support at mitgcm.org>
> Subject: [MITgcm-support] exch2 and autogenerated grids (llc, cs,
> etc.)
> Message-ID:
> <
> CAJAZx5ChzkVyF2ru1ZHkTCKx4-3Ts-wyGhVnfxeQJ2eTRcUKEg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi,
>
> After avoiding this issue for a long time, I am finally trying to
> understand how the new auto-generated grids work (in particular the llc
> grids).
>
> Is this documentation up to date?
> http://mitgcm.org/public/r2_manual/latest/online_documents/node233.html
>
> For the global_oce_llc90 setup, the input files seem very simple, i.e. data
> file just has
> usingCurvilinearGrid=.TRUE.,
>
> and data.exch2 has
> W2_printMsg= 0,
> W2_mapIO = 1,
> preDefTopol=0,
> dimsFacets(1:10) = 90, 270, 90, 270, 90, 90, 270, 90, 270, 90,
> facetEdgeLink(1:4,1)= 3.4, 0. , 2.4, 5.1,
> facetEdgeLink(1:4,2)= 3.2, 0. , 4.2, 1.3,
> facetEdgeLink(1:4,3)= 5.4, 2.1, 4.4, 1.1,
> facetEdgeLink(1:4,4)= 5.2, 2.3, 0. , 3.3,
> facetEdgeLink(1:4,5)= 1.4, 4.1, 0. , 3.1,
>
> This is evidently enough information to completely specify the grid
> geometry. But I can't figure out where in the code the geometry is actually
> calculated. In ini_curvilinear_grid.F, it looks like it is just reading the
> geometry from horizGridFile (i.e. tile.0001.mitgrid). So when do these
> horizGridFiles get written?
>
> Just looking for some hints to get started on understanding this important
> but intimidating subject.
>
> Thanks,
> Ryan
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://mitgcm.org/pipermail/mitgcm-support/attachments/20151022/5a29c4c2/attachment-0001.htm
> >
>
> ------------------------------
>
> Message: 4
> Date: Thu, 22 Oct 2015 23:34:34 -0400
> From: Jean-Michel Campin <jmc at ocean.mit.edu>
> To: mitgcm-support at mitgcm.org
> Subject: Re: [MITgcm-support] exch2 and autogenerated grids (llc, cs,
> etc.)
> Message-ID: <20151023033434.GB28222 at ocean.mit.edu>
> Content-Type: text/plain; charset=us-ascii
>
> Hi Ryan,
>
> There might be some confusion here:
> 1) this part of the documentation:
> > http://mitgcm.org/public/r2_manual/latest/online_documents/node233.html
> is NOT up-to-date. No need to use any matlab script (driver.m) from
> MITgcm/utils/exch2/matlab-topology-generator to set-up the
> correct/customized
> exch2 topology. See the top of the 2 README files
> in: utils/exch2/matlab-topology-generator and in: utils/exch2/code-mods
>
> Setting SIZE.h and data.exch2 should be enough to get pkg/exch2
> tile-topology
> set-up.
> But this is (mostly) independent from the the input grid-files
> which provides lat,lon position, grid-spacing and grid-cell area.
>
> 2) Regarding grid files (horizGridFile= ...) used with
> usingCurvilinearGrid=T,
> I am not aware of any MITgcm fortran code that would generate these files.
> Some set of grid-files are available (in some verification exp., also in
> MITgcm_contrib area) but otherwise you will need to generate these files.
> There has been few email exchange on support list related to how generate
> grid-files for cubed-sphere grid ; and you can take a look at the recently
> publish paper in GMD about ECCO-v4, with some information regarging the
> lap-lon-cap grid and grid-files.
>
> Cheers,
> Jean-Michel
>
> On Thu, Oct 22, 2015 at 05:16:17PM -0400, Ryan Abernathey wrote:
> > Hi,
> >
> > After avoiding this issue for a long time, I am finally trying to
> > understand how the new auto-generated grids work (in particular the llc
> > grids).
> >
> > Is this documentation up to date?
> > http://mitgcm.org/public/r2_manual/latest/online_documents/node233.html
> >
> > For the global_oce_llc90 setup, the input files seem very simple, i.e.
> data
> > file just has
> > usingCurvilinearGrid=.TRUE.,
> >
> > and data.exch2 has
> > W2_printMsg= 0,
> > W2_mapIO = 1,
> > preDefTopol=0,
> > dimsFacets(1:10) = 90, 270, 90, 270, 90, 90, 270, 90, 270, 90,
> > facetEdgeLink(1:4,1)= 3.4, 0. , 2.4, 5.1,
> > facetEdgeLink(1:4,2)= 3.2, 0. , 4.2, 1.3,
> > facetEdgeLink(1:4,3)= 5.4, 2.1, 4.4, 1.1,
> > facetEdgeLink(1:4,4)= 5.2, 2.3, 0. , 3.3,
> > facetEdgeLink(1:4,5)= 1.4, 4.1, 0. , 3.1,
> >
> > This is evidently enough information to completely specify the grid
> > geometry. But I can't figure out where in the code the geometry is
> actually
> > calculated. In ini_curvilinear_grid.F, it looks like it is just reading
> the
> > geometry from horizGridFile (i.e. tile.0001.mitgrid). So when do these
> > horizGridFiles get written?
> >
> > Just looking for some hints to get started on understanding this
> important
> > but intimidating subject.
> >
> > Thanks,
> > Ryan
>
> > _______________________________________________
> > MITgcm-support mailing list
> > MITgcm-support at mitgcm.org
> > http://mitgcm.org/mailman/listinfo/mitgcm-support
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 22 Oct 2015 23:52:26 -0400
> From: Ryan Abernathey <ryan.abernathey at gmail.com>
> To: "mitgcm-support at mitgcm.org" <mitgcm-support at mitgcm.org>
> Subject: Re: [MITgcm-support] exch2 and autogenerated grids (llc, cs,
> etc.)
> Message-ID:
> <CAJAZx5C5RvUgfOPc-AsdxjxihEFga0hJb5y+ruDm=
> rxf3cZyXw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Thanks for the reply. You cleared up one source of confusion: the grid
> files are NOT generated by MITgcm. They need to be generated by the user.
> (Correct?)
>
> But I am still confused about one thing:
> Where is the script that generates the input files for the llc
> configurations?
> If I could see the logic within this script, I feel like I could maybe
> start to understand how the llc grid works.
>
> -Ryan
>
> On Thu, Oct 22, 2015 at 11:34 PM, Jean-Michel Campin <jmc at ocean.mit.edu>
> wrote:
>
> > Hi Ryan,
> >
> > There might be some confusion here:
> > 1) this part of the documentation:
> > >
> http://mitgcm.org/public/r2_manual/latest/online_documents/node233.html
> > is NOT up-to-date. No need to use any matlab script (driver.m) from
> > MITgcm/utils/exch2/matlab-topology-generator to set-up the
> > correct/customized
> > exch2 topology. See the top of the 2 README files
> > in: utils/exch2/matlab-topology-generator and in: utils/exch2/code-mods
> >
> > Setting SIZE.h and data.exch2 should be enough to get pkg/exch2
> > tile-topology
> > set-up.
> > But this is (mostly) independent from the the input grid-files
> > which provides lat,lon position, grid-spacing and grid-cell area.
> >
> > 2) Regarding grid files (horizGridFile= ...) used with
> > usingCurvilinearGrid=T,
> > I am not aware of any MITgcm fortran code that would generate these
> files.
> > Some set of grid-files are available (in some verification exp., also in
> > MITgcm_contrib area) but otherwise you will need to generate these
> files.
> > There has been few email exchange on support list related to how
> generate
> > grid-files for cubed-sphere grid ; and you can take a look at the
> recently
> > publish paper in GMD about ECCO-v4, with some information regarging the
> > lap-lon-cap grid and grid-files.
> >
> > Cheers,
> > Jean-Michel
> >
> > On Thu, Oct 22, 2015 at 05:16:17PM -0400, Ryan Abernathey wrote:
> > > Hi,
> > >
> > > After avoiding this issue for a long time, I am finally trying to
> > > understand how the new auto-generated grids work (in particular the llc
> > > grids).
> > >
> > > Is this documentation up to date?
> > >
> http://mitgcm.org/public/r2_manual/latest/online_documents/node233.html
> > >
> > > For the global_oce_llc90 setup, the input files seem very simple, i.e.
> > data
> > > file just has
> > > usingCurvilinearGrid=.TRUE.,
> > >
> > > and data.exch2 has
> > > W2_printMsg= 0,
> > > W2_mapIO = 1,
> > > preDefTopol=0,
> > > dimsFacets(1:10) = 90, 270, 90, 270, 90, 90, 270, 90, 270, 90,
> > > facetEdgeLink(1:4,1)= 3.4, 0. , 2.4, 5.1,
> > > facetEdgeLink(1:4,2)= 3.2, 0. , 4.2, 1.3,
> > > facetEdgeLink(1:4,3)= 5.4, 2.1, 4.4, 1.1,
> > > facetEdgeLink(1:4,4)= 5.2, 2.3, 0. , 3.3,
> > > facetEdgeLink(1:4,5)= 1.4, 4.1, 0. , 3.1,
> > >
> > > This is evidently enough information to completely specify the grid
> > > geometry. But I can't figure out where in the code the geometry is
> > actually
> > > calculated. In ini_curvilinear_grid.F, it looks like it is just reading
> > the
> > > geometry from horizGridFile (i.e. tile.0001.mitgrid). So when do these
> > > horizGridFiles get written?
> > >
> > > Just looking for some hints to get started on understanding this
> > important
> > > but intimidating subject.
> > >
> > > Thanks,
> > > Ryan
> >
> > > _______________________________________________
> > > 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
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://mitgcm.org/pipermail/mitgcm-support/attachments/20151022/f9bdba5a/attachment.htm
> >
>
> ------------------------------
>
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-support
>
>
> End of MITgcm-support Digest, Vol 148, Issue 13
> ***********************************************
>
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-support
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mitgcm.org/pipermail/mitgcm-support/attachments/20151023/7d878168/attachment-0001.htm>
More information about the MITgcm-support
mailing list