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, [email protected] 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: [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
>>>
>>
>>
>>
>
>
