[MITgcm-support] (no subject)
Liam Brannigan
Liam.Brannigan at physics.ox.ac.uk
Fri Oct 23 05:38:34 EDT 2015
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
***********************************************
More information about the MITgcm-support
mailing list