Looks like you're right. I've changed the arch.make accordingly. Here's the output for posterity.
> The KIND for SINGLE precision: 4 > The RANGE for SINGLE precision: 37 > The PRECISION for SINGLE precision: 6 > > The KIND for DOUBLE precision: 8 > The RANGE for DOUBLE precision: 307 > The PRECISION for DOUBLE precision: 15 > > Listing different REAL KIND's > KIND PRECISION RANGE > 4 6 37 > 8 15 307 > 16 31 291 > > Listing different INTEGER KIND's sorted on RANGE > KIND RANGE > 1 2 > 2 4 > 4 9 > 8 18 I do notice that during the compile process it spits out: checking for kind number produced by kind(1.0)... 1 > checking for kind number produced by kind(1.0d0)... 8 > checking for kind number produced by selected_real_kind(6,34)... 1 > checking for kind number produced by selected_real_kind(15,300)... 8 I doubt this has anything to do with my error, but it seems like its worth looking into. -AdamC Adam S. Cadien PhD. Candidate School of Physics, Astronomy & Computational Sciences George Mason University 4400 University Dr., MSN 6A2 Fairfax, VA 22030, USA On Wed, Nov 5, 2014 at 1:51 PM, Nick Papior Andersen <[email protected]> wrote: > I am not sure about compiling on a BlueGene platform, neither the xlf > compiler. > However, your precision on single seems weird. > Does single precision really correspond to kind=1? > Typically kind=4 for single, and kind=8 for double. > You can try out this small program to check if that really is the case. > > Again this is a long shot, but might pose problems. > > 2014-11-05 18:29 GMT+00:00 Adam Cadien <[email protected]>: > >> Hello; >> >> I'm trying to run Siesta on the Mira BlueGene/Q supercomputer, using the >> IBM xlf compilers. I've run to my wits end trying to get this working so I >> was hoping one of you might be able to help. >> I can get through the compiler process error free but when running siesta >> I get a Core Dump with no errors or warnings. I ran it through GDB and >> checked the backtrace and get: >> >> Program received signal SIGABRT, Aborted. >>> 0x0000000001e3350c in raise (sig=6) at >>> ../nptl/sysdeps/unix/sysv/linux/raise.c:67 >>> 67 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. >>> in ../nptl/sysdeps/unix/sysv/linux/raise.c >>> (gdb) backtrace >>> #0 0x0000000001e3350c in raise (sig=6) at >>> ../nptl/sysdeps/unix/sysv/linux/raise.c:67 >>> #1 0x0000000001dc8694 in abort () at abort.c:92 >>> #2 0x0000000001c3ef88 in PAMI::BgqJobPersonality::BgqJobPersonality >>> (this=<value optimized out>) >>> at >>> /bgsys/source/srcV1R2M2.1830/comm/sys/buildtools/pami/common/bgq/BgqPersonality.h:102 >>> #3 0x0000000001c4ccb4 in PAMI::Global::Global (this=0x2588c20) >>> at >>> /bgsys/source/srcV1R2M2.1830/comm/sys/buildtools/pami/common/bgq/Global.h:110 >>> #4 0x0000000001c3cc6c in __static_initialization_and_destruction_0 () >>> at >>> /bgsys/source/srcV1R2M2.1830/comm/sys/buildtools/pami/common/bgq/BgqGlobal.cc:25 >>> #5 global constructors keyed to __global() () >>> at >>> /bgsys/source/srcV1R2M2.1830/comm/sys/buildtools/pami/common/bgq/BgqGlobal.cc:70 >>> #6 0x0000000001e7279c in .__do_global_ctors_aux () >>> #7 0x00000000010001b4 in ._init () >>> #8 0x0000000001dbf940 in __libc_csu_init (argc=1, argv=0xfffffffe598, >>> envp=0xfffffffe5a8) at elf-init.c:120 >>> #9 0x0000000001dbef34 in generic_start_main (main=@0x23c9408: 0x1170740 >>> <siesta>, argc=1, ubp_av=0xfffffffe598, >>> auxvec=0xfffffffe780, init=@0x2439828: 0x1dbf8b0 <__libc_csu_init>, >>> fini=@0x2439810: 0x1dbf810 <__libc_csu_fini>, >>> rtld_fini=0, stack_end=<value optimized out>) at >>> ../csu/libc-start.c:185 >>> #10 0x0000000001dbf294 in __libc_start_main (argc=1, >>> ubp_av=0xfffffffe598, ubp_ev=<value optimized out>, >>> auxvec=0xfffffffe780, rtld_fini=0, stinfo=0x1e73e40, >>> stack_on_entry=0xfffffffe590) >>> at ../sysdeps/unix/sysv/linux/powerpc/libc-start.c:194 >>> #11 0x0000000000000000 in ?? () >> >> >> I suspect the problem is one of the resources I'm using is not correct >> because the raise call is coming from a BG/Q library. The arch.make is >> below; >> >> .SUFFIXES: >>> .SUFFIXES: .f .F .o .a .f90 .F90 >>> SIESTA_ARCH=powerpc64-bgq-linux-gnu--unknown >>> FPP= >>> FPP_OUTPUT= >>> FC=mpixlf90_r >>> RANLIB=powerpc64-bgq-linux-ranlib >>> SYS=nag >>> SP_KIND=1 >>> DP_KIND=8 >>> KINDS=$(SP_KIND) $(DP_KIND) >>> FFLAGS= >>> FFLAGS_DEBUG=-g >>> FPPFLAGS= -WF,-DMPI -WF,-DFC_HAVE_ABORT >>> LDFLAGS= >>> ARFLAGS_EXTRA= >>> FCFLAGS_fixed_f=-qfixed -qsuffix=cpp=f >>> FCFLAGS_free_f90= >>> FPPFLAGS_fixed_F=-qfixed -qsuffix=cpp=F >>> FPPFLAGS_free_F90= >>> BLAS_LIBS=/soft/libraries/essl/current/lib64/libesslbg.a >>> LAPACK_LIBS=/soft/libraries/alcf/current/xl/LAPACK/lib/liblapack.a >>> BLACS_LIBS=/soft/libraries/alcf/current/xl/SCALAPACK/lib/libscalapack.a >>> >>> SCALAPACK_LIBS=/soft/libraries/alcf/current/xl/SCALAPACK/lib/libscalapack.a >>> COMP_LIBS=dc_lapack.a >>> NETCDF_LIBS= >>> NETCDF_INTERFACE= >>> LIBS=$(SCALAPACK_LIBS) $(BLACS_LIBS) $(LAPACK_LIBS) $(BLAS_LIBS) >>> $(NETCDF_LIBS) >>> #SIESTA needs an F90 interface to MPI >>> #This will give you SIESTA's own implementation >>> #If your compiler vendor offers an alternative, you may change >>> #to it here. >>> MPI_INTERFACE=libmpi_f90.a >>> MPI_INCLUDE=. >>> #Dependency rules are created by autoconf according to whether >>> #discrete preprocessing is necessary or not. >>> .F.o: >>> $(FC) -c $(FFLAGS) $(INCFLAGS) $(FPPFLAGS) $(FPPFLAGS_fixed_F) $< >>> .F90.o: >>> $(FC) -c $(FFLAGS) $(INCFLAGS) $(FPPFLAGS) $(FPPFLAGS_free_F90) $< >>> .f.o: >>> $(FC) -c $(FFLAGS) $(INCFLAGS) $(FCFLAGS_fixed_f) $< >>> .f90.o: >>> $(FC) -c $(FFLAGS) $(INCFLAGS) $(FCFLAGS_free_f90) $< >> >> >> Any thoughts on how to move forward debugging this? I've tried playing >> with the MPI configuration. I'd rather not switch to GCC as run times are >> generally 2-5x slower than XLF on this machine. >> >> Thanks for the help. >> -AdamC >> >> Adam S. Cadien >> PhD. Candidate >> School of Physics, Astronomy & Computational Sciences >> George Mason University >> 4400 University Dr., MSN 6A2 >> Fairfax, VA 22030, USA >> > > > > -- > Kind regards Nick >
