The ABINIT Users Mailing List ( CLOSED )

["Anglade Pierre-Matthieu" <anglade@gmail.com>]

Hi,

I can remember such kind of error messages with intel compiler.
Sometime Abinit expect a certain size for a variables when they are
transmitted from one function to the other . But since the variable is
sometimes unused it is not allocated. And you can get such error
message.
For your own case this is probably a little bit different. May be
Intel compiler has a different way to treat array large than a certain
size and PAWRAD has growth too much.

Do you reproduce this same bug with other compilers ? For instance g95
? This last one, if you compile with "-g -ftrace=full' will give you
lot of error about the precise instruction that is badly handled in
the code.
Have you try debugging and runtime checking option of intel compiler ?
They will likely also give you lots of useful information about the
location of the bug.

regards

PMA

On 9/21/07, Paul Fons <paul-fons@aist.go.jp> wrote:
>
> Greetings,
>   I was doing a convergence study for a structure for various cutoff
> energies 20,30,40, and 50 Ha.  Strangely, all worked fine until I reached 50
> Ha.  For ecut 50 Ha, abinit crashes without warning during the first SCF
> loop. The version of abinit used is the current version of 5.4.3 compiled
> with the latest Intel (10.0.17) fortran compiler on darwin.  All of the
> automatic tests of the build work fine.  I have not seen strange crashes of
> this type before and would like to track down the cause.  As the intel
> compiler has a check option which generates runtime code that checks for
> proper memory use, I compiled a "debug" version of abinit and ran the same
> code again.  I would use the 64 bit debugger that comes with the compiler to
> nail down a little bit more about location, but it has trouble finding some
> symbols in dynamic libraries upon reading of the abinis binary that put it
> into a seemingly endless error loop (that has nothing to do with the abinit
> memory problem).
>
> Any ideas as to what might be going wrong?
>
> The input file as well as the full output (up to the crash) is included
> below.  The code is compiled using 64 bits, so memory allocation failures
> should not be a problem.
>
> The last breath of the run is below.  The Intel compiler reports that PAWRAD
> is being used without being allocated.
>
>
>
>
> == DATASET  1
> ==================================================================
>
>  dtsetcopy : copying area  algalch    the actual size (           3
>  ) of the index (           1 )  differs from its standard size (
> 0 )
>  dtsetcopy : copying area  kberry     the actual size (          20
>  ) of the index (           2 )  differs from its standard size (
> 1 )
>  dtsetcopy : copying area  nband      the actual size (          10
>  ) of the index (           1 )  differs from its standard size (
> 1 )
>   dtsetcopy : allocated densty= T
>  dtsetcopy : copying area  mixalch    the actual size (           3
>  ) of the index (           1 )  differs from its standard size (
> 0 )
>  dtsetcopy : copying area  mixalch    the actual size (           3
>  ) of the index (           2 )  differs from its standard size (
> 0 )
>  dtsetcopy : copying area  shiftk     the actual size (           8
>  ) of the index (           2 )  differs from its standard size (
> 1 )
>
>  getdim_nloc : deduce lmnmax  =  16, lnmax  =   4,
>                       lmnmaxso=  16, lnmaxso=   4.
> forrtl: severe (408): fort: (8): Attempt to fetch from allocatable variable
> PAWRAD when it is not allocated
>
>
>
>
> The content of the (4) status files is also included here
>  Status file, with repetition rate  49, status number    99
>
>   Level abinit         : call driver
>   Level driver         : call gstate
>   Level gstate         : call scfcv
>   Level scfcv          : call vtorho
>   istep   =    1
>   Level vtorho         : loop ikpt
>   isppol  =    1
>   ikpt    =    4
>
>  Status file, with repetition rate  49, status number    99
>
>   Level abinit         : call driver
>   Level driver         : call gstate
>   Level gstate         : call scfcv
>   Level scfcv          : call vtorho
>   istep   =    1
>   Level vtorho         : call vtowfk
>   isppol  =    1
>   ikpt    =    6
>   Level vtowfk         : deallocate
>
>  Status file, with repetition rate  49, status number    99
>
>   Level abinit         : call driver
>   Level driver         : call gstate
>   Level gstate         : call scfcv
>   Level scfcv          : call vtorho
>   istep   =    1
>   Level vtorho         : call vtowfk
>   isppol  =    1
>   ikpt    =    9
>   Level vtowfk         : call pw_orthon
>   inonsc  =    2
>
>  Status file, with repetition rate  49, status number    50
>
>   Level abinit         : call driver
>   Level driver         : call gstate
>   Level gstate         : call scfcv
>   Level scfcv          : call vtorho
>   istep   =    1
>   Level vtorho         : call vtowfk
>   isppol  =    1
>   ikpt    =   10
>   Level vtowfk         : call normev
>   inonsc  =    1
>
>
>
>
>
>
>
>
>
>
> Dr. Paul Fons
>
> Nano-Optics Reseach Team
>
> Team Leader
>
> National Institute for Advanced Industrial Science & Technology
>
> METI
>
> Center for Applied Near-Field Optics Research (CANFOR)
>
> AIST Central 4, Higashi 1-1-1
>
> Tsukuba, Ibaraki JAPAN 305-8568
>
>
>
>
> tel. +81-298-61-5636
>
> fax. +81-298-61-2939
>
>
>
>
> email: paul-fons@aist.go.jp
>
>
> The following lines are in a Japanese font
>
> 〒305-8562 茨城県つくば市つくば中央東 1-1-1
> 産業技術総合研究所
> 近接場光応用工学研究センター
> 近接場光基礎研究チーム　チーム長
> ポール・フォンス
>
>
>
>
>
>


-- 
Pierre-Matthieu Anglade