[Wien] crash in lapw0 [and other crashes too...]

Martin Gelfand gelfand at lamar.ColoState.EDU
Fri Oct 3 23:12:56 CEST 2003


I'm running wien2k_2 (yes, yes, I should move to version 3 ...)
and two attempts to relax internal coordinates via min_lapw
have failed, with different crashes different times.  
(Hardware/software note: dual PIII-800 with 4G of ram, Debian stable,
Lahey compiler, ATLAS libs.)  Each time I have started clean,
with just the initial struct file and the inM file, then initialized
the calculation, then did an SCF cycle to convergence, then
tried min_lapw.  

Here's my latest example, first the log-file (where the end of the
initial SCF run appears, at the top)
$ tail ':log'
Fri Oct  3 05:09:48 MDT 2003> (x) lapw1 CsMoS lapw1
Fri Oct  3 06:08:16 MDT 2003> (x) lapw2 CsMoS lapw2
Fri Oct  3 06:27:17 MDT 2003> (x) lcore CsMoS lcore
Fri Oct  3 06:27:18 MDT 2003> (x) mixer CsMoS mixer
>   (min_lapw) options:
>   (min_lapw) recover inm-file & call job run_lapw -I -fc 1. -renorm -i
40
>   (run_lapw) options: -I -fc 1. -renorm -i 40
Fri Oct  3 14:46:43 MDT 2003> (x) mixer CsMoS mixer
Fri Oct  3 14:47:01 MDT 2003> (x) lapw0 CsMoS lapw0
>>> (min_lapw) status after run_lapw -I -fc 1. -renorm -i 40 \: 9 -> exit

and what appeared in the shell at the time of the crash
$ min_lapw
run_lapw -I -fc 1. -renorm -i 40
 MIXER END
in cycle 2    ETEST: .0000055000000000   CTEST: .0000027
In DASIN(dx) or ASIN(dx) or DACOS(dx) or ACOS(dx), DABS(dx).gt.1.0 (dx=nan
               ).
 Error occurs at or near line 66 of efg_
 Called from or near line 856 of MAIN__
>>> (min_lapw) status after run_lapw -I -fc 1. -renorm -i 40 \: 9 -> exit

Any ideas why that error might occur?  (I can see in the code what
the argument of the arc-cosine is, eivec(1,1)/anorm, but I'm not
sure where to go from there...)  What's maddening to me is that
I did _almost_ the exact same procedure, min_lapw got through enough
of its cycle to give a first round of displacements, and then there
was a segmentation fault reported in lapw2.  The only difference
was one time I ran with k-point parallelization (the lapw2 failure),
the other time without.  I've run many "straight" SCF cycles without
encountering crashes.

Thanks in advance for any and all suggestions.

Martin Gelfand
Dept of Physics, Colorado State University




More information about the Wien mailing list