If the kind really is wrong, then you will most likely have memory leaks....
2014-11-05 19:05 GMT+00:00 Adam Cadien <[email protected]>: > 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 >> > > -- Kind regards Nick
