[MITgcm-support] domain size limit?

fancer lancer fancer.lancer at gmail.com
Tue Dec 3 08:53:06 EST 2013


Martin,
Is it the only error produced by the compiler/linker or there are some
additional warnings or messages? If so could you, please, post them here?
It can be useful.

Sincerely,
-Sergey


On Tue, Dec 3, 2013 at 4:50 PM, Martin Losch <Martin.Losch at awi.de> wrote:

> Hi Sergey,
>
> The compiler flags are the ones that you can find in
> tools/build_options/darwin_amd64_gfortran, so no 32bit related parameters
> (-arch i386 is commented out).
>
> I saw that thread earlier today, but I cannot extract solution for the
> MITgcm. I have no idea about C, and as far as I know/can see, including
> headers is always the first stuff in all files.
>
>  Martin
>
> On Dec 3, 2013, at 1:38 PM, fancer lancer <fancer.lancer at gmail.com> wrote:
>
> > Hi Martin,
> > Ok, you use x86_64 version of compiler. And I suppose you don't specify
> any additional parameters to the compiler like '-m32'.
> > Alas I don't have an Apple computer nearby to check the actual cause of
> the problem. But I guess the clue to solve the issue may be found in the
> thread:
> > http://lists.apple.com/archives/xcode-users/2012/Jun/msg00118.html
> > And additional explanation is here:
> > http://lists.apple.com/archives/xcode-users/2012/Jun/msg00126.html
> >
> > Sincerely,
> > -Sergey
> >
> >
> >
> >
> > On Tue, Dec 3, 2013 at 3:43 PM, Martin Losch <Martin.Losch at awi.de>
> wrote:
> > Hi Sergey,
> >
> > I don’t know if Ryan’s compiler is the same (probably similar), but
> here’s mine:
> >
> > csysm15::build> gfortran -v
> > Using built-in specs.
> > COLLECT_GCC=gfortran
> >
> COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-apple-darwin13.0.0/4.9.0/lto-wrapper
> > Target: x86_64-apple-darwin13.0.0
> > Configured with: ../gcc-4.9-20130929/configure
> --enable-languages=c,c++,fortran
> > Thread model: posix
> > gcc version 4.9.0 20130929 (experimental) (GCC)
> >
> > Martin
> >
> > On Dec 3, 2013, at 9:48 AM, fancer lancer <fancer.lancer at gmail.com>
> wrote:
> >
> > > Hi Ryan,
> > >
> > > Could you please, show the result of the command "gfortran -v". I
> suppose, that you used the 32-bit version of the compiler that is why you
> overcame the limit.
> > >
> > > Sincerely,
> > > -Sergey
> > >
> > >
> > > On Tue, Dec 3, 2013 at 12:29 PM, Martin Losch <Martin.Losch at awi.de>
> wrote:
> > > Hi Ryan,
> > >
> > > I can only reproduce the problem with tutorial_barotropic_gyre (and
> gcc/gfortran 4.9 on OSX 10.9).
> > >
> > > By how much do you have to repduce the domain size to make it work?
> > >
> > > The simplest solution that I found: instead of sNy=1600 and nSy = 1
> use sNy=800 and nSy = 2. It’s a little bit of cheating, isn’t it?
> > >
> > > Martin
> > >
> > > On Dec 3, 2013, at 6:00 AM, Ryan Abernathey <ryan.abernathey at gmail.com>
> wrote:
> > >
> > > > Dear Super Modelers,
> > > >
> > > > I found a weird error when trying to compile a large domain (500 x
> 1600 x 1) on a single processor. On the final link stage of the build, I
> get:
> > > > ld: 32-bit RIP relative reference out of range (2162237024 max is
> +/-4GB): from _find_beta__ (0x100227200) to _rhoden.4514 (0x18103AE80) in
> '_find_beta__' from find_alpha.o for architecture x86_64
> > > > The error disappears if I just reduce sNx * sNy. I guess this has
> something to do with running out of memory address space? Is it weird that
> "32-bit RIP" is being used even though my platform is 64 bit?
> > > >
> > > > My one weak attempt to overcome this was by adding -fPIC to my
> FFLAGS. No success.
> > > >
> > > > Is there any way to overcome this problem, or am I hitting some kind
> of fundamental limit to the domain size?
> > > >
> > > > Thanks for your suggestions,
> > > > Ryan
> > > >
> > > >
> > > > My platform is Mac OX 10.8.5, Intel Core i7, gcc version 4.2.1 (via
> xcode), gfortran GNU Fortran (GCC) 4.7.1. My optfile is the default
> darwin_amd64_gfortran.
> > > >
> > > > From my SIZE.h:
> > > >      &           sNx = 500,
> > > >      &           sNy = 1600,
> > > >      &           OLx =   4,
> > > >      &           OLy =   4,
> > > >      &           nSx =   1,
> > > >      &           nSy =   1,
> > > >      &           nPx =   1,
> > > >      &           nPy =   1,
> > > >      &           Nx  = sNx*nSx*nPx,
> > > >      &           Ny  = sNy*nSy*nPy,
> > > >      &           Nr  =   1)
> > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mitgcm.org/pipermail/mitgcm-support/attachments/20131203/dc748c60/attachment-0001.htm>


More information about the MITgcm-support mailing list