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

[Peter Blaha]

Hi,

You must not start    min_lapw, when you have an "unsaved" run_lapw status.
w2web gives you a strong warning.
min_lapw with default options will run mixer (-renorm), because it thinks
you have new positions. But with the old case.broyd* files this produces
a wrong case.clmsum file (NANs ?)

Either do:

init_lapw
produce proper inM file
min_lapw


or:
init_lapw
run_lapw -fc 1
min_lapw -m       (runs just for seconds)
save_lapw case_1
cp case.struct1 case.struct
min_lapw


The previous error in lapw2 could be for similar reasons ? or due to a too
large mixing in case.inm

Regards

> 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
>
> _______________________________________________
> Wien mailing list
> Wien at zeus.theochem.tuwien.ac.at
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>


                                      P.Blaha
--------------------------------------------------------------------------
Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
Phone: +43-1-58801-15671             FAX: +43-1-58801-15698
Email: blaha at theochem.tuwien.ac.at    WWW: http://info.tuwien.ac.at/theochem/
--------------------------------------------------------------------------