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
kinds.f90
Description: Binary data
