Dear Salvador and Ricardo, I have performed what Salvador suggested and by inserting "-g -O0 -traceback" in the arch.make, I recompiled the code. Everything seems fine except for a line that reads: "configure: Could not determine type of compiler". Anyway, I append the message when running configure, at the end of my email.
The siesta version I am using is: siesta-3.0-rc2. And I am indeed using the intel compiler version 10.0. In fact, when I run pdosxml I get the same error message, that is: ./pdosxml GaNHMnrt3xrt3.PDOS > GaNHMnrt3xrt3.PDOS.dat Found nspin element NOTE: Spin polarized system There will be two PDOS columns in the output file Orbital:(n.l.m.z.index.atom_index.species): 3 0 0 1 745 61 Mn forrtl: severe (174): SIGSEGV, segmentation fault occurred Image PC Routine Line Source pdosxml 00000000004057A2 Unknown Unknown Unknown pdosxml 00000000004094C6 Unknown Unknown Unknown pdosxml 0000000000406565 Unknown Unknown Unknown pdosxml 0000000000405042 Unknown Unknown Unknown libc.so.6 000000322861D994 Unknown Unknown Unknown pdosxml 0000000000404F69 Unknown Unknown Unknown Any other suggestion? Andrea --------------------------------- Message when running configure: checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking for Fortran compiler default output file name... a.out checking whether the Fortran compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU Fortran compiler... no checking whether mpif90 accepts -g... yes checking for Fortran flag needed to allow fixed-form source for .f suffix... none checking for Fortran flag needed to allow free-form source for .f90 suffix... none checking for gcc... gcc checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for fixed form Fortran preprocessor features... done. checking whether mpif90 compiles programs with cpp directives... yes checking whether mpif90 accepts -D... yes checking whether mpif90 accepts -I... yes checking whether mpif90 fulfils requested features... yes checking preprocessing mode we may therefore use... direct checking for Fortran flag needed to allow preprocessed fixed-form source for .F suffix... (cached) none checking for Fortran flag needed to allow free-form source for .F90 suffix... none checking for ranlib... ranlib configure: Could not determine type of compiler checking for mpifc... no checking for mpxlf... no checking for mpif90... mpif90 checking for MPI_Init... no checking for MPI_Init in -lmpi... no checking for MPI_Init in -lmpich... yes checking for kind number produced by kind(1.0)... checking for kind number produced by kind(1.0)... 4 checking for kind number produced by kind(1.0d0)... checking for kind number produced by kind(1.0d0)... 8 checking for kind number produced by selected_real_kind(6,34)... checking for kind number produced by selected_real_kind(6,34)... 4 checking for kind number produced by selected_real_kind(15,300)... checking for kind number produced by selected_real_kind(15,300)... 8 checking how to compile a call to FLUSH... default checking how to compile a call to ABORT... default checking how to compile DIMAG... default checking for netcdf... no checking for sgemm in -lacml... yes checking for dsygv in -lscalapack... yes checking LAPACK includes divide-and-conquer routines... yes configure: using DC_LAPACK routines packaged with SIESTA due to bug in library. Linker flag might be needed to avoid duplicate symbols checking if we can compile a BLACS program... no checking for BLACS in -lblacs... yes checking if we can compile a ScaLAPACK program... yes checking if ScaLAPACK version is sufficiently recent... yes configure: creating ./config.status config.status: creating arch.make > Hi Salvador, > > Many thanks for your suggestion. In fact, I could not recompile the code > with the options you suggested but in the same spirit (and after checking > at the configure help) I recompiled Siesta with the option: > --enable-debug > and it did not work (i.e. I did not get any other info but the same error > message). > > Any other suggestion to try? > > Andrea > >> Hi, >> >> The segmentation fault occurs whenever you are exceeding the limits of >> fixed-size arrays. Predefined sizes of arrays might have changed in >> between versions of the code. Can you recompile your code with the debug >> options: >> -g -O0 -traceback >> in order to determine the offendig line in your code? >> >> This will hopefully bring you to the specific array causing the >> problem. >> You might want to resize it accordingly. >> >> Just a suggestion, >> >> Cheers, >> -Salvador. >> >> ----- Original Message ----- >> From: [email protected] >> To: [email protected] >> Sent: Thursday, November 18, 2010 2:23:40 PM >> Subject: [SIESTA-L] pdosxml >> >> Dear all, >> >> I have a problem extracting the file with the selected Projected >> Density >> of States out of a SystemLabel.PDOS file using the program "pdosxml" >> that >> is within the directory ~/siesta/Util/pdosxml/. >> >> I can work out the PDOS correctly from the h2oh2o_dos.PDOS file that is >> in >> the example, but it is not working for my SystemLabel.PDOS file. I am >> using the siesta-3.0-rc2 version. I even tried other SystemLabel.PDOS >> files that had worked in the past with previous versions of pdos and >> they >> are not working either now. >> >> The program pdosxml starts ok but after the first orbital, stops with a >> segmentation fault error. Namely, when I execute: >> >> ./pdosxml system.PDOS > system.PDOS.dat >> >> I get an empty file in system.PDOS.dat and the following message: >> >> Found nspin element >> NOTE: Spin polarized system >> There will be two PDOS columns in the output file >> Orbital:(n.l.m.z.index.atom_index.species): 3 0 0 1 745 61 Mn >> forrtl: severe (174): SIGSEGV, segmentation fault occurred >> Image PC Routine Line >> Source >> pdosxml 000000000040577E Unknown Unknown >> Unknown >> pdosxml 00000000004094A2 Unknown Unknown >> Unknown >> pdosxml 0000000000406541 Unknown Unknown >> Unknown >> pdosxml 0000000000405042 Unknown Unknown >> Unknown >> libc.so.6 000000322861D994 Unknown Unknown >> Unknown >> pdosxml 0000000000404F69 Unknown Unknown >> Unknown >> >> I have selected in m_orbital_chooser.f90 the following option: >> wantit = ( orbid%species == "Mn" ) >> >> in order to get the Density of States on the Mn atoms. >> >> I would appreciate your help. Thanks in advance, >> >> Andrea >> >> -- >> Salvador Barraza-Lopez >> Postdoctoral Fellow >> School of Physics >> The Georgia Institute of Technology >> >> Office N205 >> 837 State Street Atlanta, Georgia 30332-0430 U.S.A >> Tel: (404) 894-0892 Fax: (404) 894-9958 >> > > >
