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

gelfand gelfand at lamar.colostate.edu
Tue Oct 7 23:17:43 CEST 2003


Dear Dr Blaha,
  Many thanks for the reply.  However, the first method does not seem to
work.  min_lapw crashes immediately with lapw0 complaining about case.clmsum,
here is the output...

run_lapw -I -fc 1. -renorm -i 40
 MIXER END
in cycle 2    ETEST: 0   CTEST: 0
An endfile record was detected in a READ statement (unit= 8).

and in fact clmsum is essentially empty.  That is the result of
mixer running, when it should not, correct?  I couldn't see an
option in min_lapw to prevent mixer from running the first time.
(And that is why I went ahead and did full scf cycles and then tried
to invoke min_lapw, in the first place.)

I'll give the second recipe a go.

Thanks again,
Martin Gelfand
Dept of Physics,
Colorado State University
>===== Original Message From Peter Blaha <pblaha at zeus.theochem.tuwien.ac.at> 
=====
>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/
>--------------------------------------------------------------------------
>
>_______________________________________________
>Wien mailing list
>Wien at zeus.theochem.tuwien.ac.at
>http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien




More information about the Wien mailing list