Dear all, I went through all the points mentioned by Alberto Garcia and unfortunately, had no success.
Interestingly, after adding the debugging options suggested by Alberto I got additional info which might enlight someone in the list :-). The message is the following: "forrtl: severe (408): fort: (2): Subscript #1 of the array DATA has value 4000001 which is greater than the upper bound of 4000000" (the complete error message is appended at the end of my email) I immediately went to check for this upper bound and found it at NMAX in m_pdos.f90 (in siesta.../Util/pdosxml). I have systematically increased NMAX and I got subsequent messages like the one above but always found that array DATA went to a value of NMAX +1 greater than NMAX... I have also recompiled the code with two newer compiler versions (namely intel-10.0.023 and intel-11.1.056, in addition to the one I was originally using intel-10.0) and got the same message. So, it seems it is not related to the compiler. I would appreciate any help and also thanks Tamas for your suggestion! Andrea PS: Error message when executing ./pdosxml system.PDOS > system.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 (408): fort: (2): Subscript #1 of the array DATA has value 4000001 which is greater than the upper bound of 4000000 Image PC Routine Line Source pdosxml 0000000000487496 Unknown Unknown Unknown pdosxml 0000000000486692 Unknown Unknown Unknown pdosxml 000000000044620E Unknown Unknown Unknown pdosxml 0000000000412A8E Unknown Unknown Unknown pdosxml 0000000000411A14 Unknown Unknown Unknown pdosxml 0000000000406327 m_pdos_mp_end_ele 150 m_pdos.f90 pdosxml 000000000040A97E Unknown Unknown Unknown pdosxml 0000000000407612 MAIN__ 45 pdosxml.f90 pdosxml 0000000000405042 Unknown Unknown Unknown libc.so.6 000000322861D994 Unknown Unknown Unknown pdosxml 0000000000404F69 Unknown Unknown Unknown > Hi, Andrea, > > A few points about this: > > 1. You need to make sure that you also recompile pdosxml after recompiling > Siesta > with the new options. Go to Util/pdosxml and do "make clean ; make". > > 2. A good combination of checking options for the Fortran compiler is: > > FFLAGS= -O0 -g -debug full -C -traceback > > 3. As stated in the manual, relying only in "configure" is not > appropriate. > It pays to review the documented arch.make example in Src/Sys, and the other > actual example files stored there. > > 4. Here we learn that your compiler is Intel 10.0. It is a bit old. This is > not necessarily a bad thing (newer versions introduce bugs), but the fact > that > it is a .0 version makes it more likely that your problem might be caused > by > a compiler bug. It is always good practice to try to replicate the problem > with another > compiler. Gfortran is free and quite adequate. > > 5. Finally, is there anything in the .PDOS file that looks suspicious? > There is a limit of 4000 in the size of the internal arrays (number of > energy points), > but the program should stop with an "array full" message instead of > crashing when that > limit is reached. > > Best regards, > > Alberto > > > > > > On Nov 23, 2010, at 8:02 PM, bar...@tandar.cnea.gov.ar wrote: > >> 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: bar...@tandar.cnea.gov.ar >>>> To: siesta-l@uam.es >>>> 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 > >
