Andrea, Line 150 of m_pdos.f90 reads:
dos1 = dos1 + data(1:ndata:2) This means that it will access the elements of the array data in the following way: data(1), data(3), ... , data (3999999) However, it seems to be accessing the element NMAX+1, which does not exist since your array has NMAX elements, hence the error. Since you are using ifort, what level of optimization are you using? What are the compilation flags? More importantly: are you by any chance using -O3 for the compilation? Ifort is buggy, and high levels of optimization can sometimes produce unpredictable errors. Try using -O2 for optimization, and if it still falis, compile siesta serially with gfortran (preferably) or g95, not going beyond -O2, even if just for using pdosxml with this version. I had a bad concept of gfortran and a good concept of ifort, in terms of efficiency, even though I knew ifort was a damn buggy compiler. However, with some recent tests I have performed for comparing gfortran with ifort, I am thinking of starting to invest some time in succeding in compiling everything I can with gfortran so I can eventually abandon ifort completely, mkl and all. Cheers, Marcos On Fri, Nov 26, 2010 at 12:55 PM, <bar...@tandar.cnea.gov.ar> wrote: > 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 > > > > > > > > >
