[Wien] segfault in mixer

[Laurence Marks]

Aha!

There is some code inside mixer.F which reduces the number of PW's to only
those which are non-zero. With your clmval this is zero, so the array kzz
in setn probably has a size of (3,0) which is zero. A zero size array will
lead to a SIGSEGV, I suspect that ifort has decided that line 27 is where
it is going to prefetch the first values of kzz (i.e. kzz(1,2) at line 30).

Something went wrong earlier either (or both) in lapw1 & lapw2.

N.B., I will try and remember to add a trap for this in mixer, but it is
not really a fault in that code.

On Wed, Nov 11, 2015 at 8:20 AM, Elias Assmann <elias.assmann at gmail.com>
wrote:

> On 11/11/2015 02:53 PM, Peter Blaha wrote:
> > Anything in case.outputm ?
>
> No warnings or errors.  Apart from the size information I quoted, the
> only “suspicious” thing is the first line
>
>  filename of case.inc: case.incup
>
> where case.incup is empty.  But I checked other calculations and
> case.incup seems to be empty always.
>
> > setn has not much to do with the actual clmsum/val file input, except
> > when the number of PW is zero (check out clmval and clmsum and
> > clmsum_old files, if the K-lists are ok.), as this fft array gets
> > allocated with nkknew1
>
> The clmval files are zero (the whole files), but there are definitely
> plane waves:
>
> $ grep -e PW *.clmvalup -A10
>              594657 NUMBER OF PW
>        0    0    0 0.000000000000E+00 0.000000000000E+00
>        0    0   -1 0.000000000000E+00 0.000000000000E+00
>        0    0    1 0.000000000000E+00 0.000000000000E+00
>        0    0   -2 0.000000000000E+00 0.000000000000E+00
>        0    0    2 0.000000000000E+00 0.000000000000E+00
>        0    0   -3 0.000000000000E+00 0.000000000000E+00
>        0    0    3 0.000000000000E+00 0.000000000000E+00
>        0    0   -4 0.000000000000E+00 0.000000000000E+00
>        0    0    4 0.000000000000E+00 0.000000000000E+00
>        0    0   -5 0.000000000000E+00 0.000000000000E+00
>
> $ grep -e PW *.clmsum -A10
>              594657 NUMBER OF PW                                 Change
>         Residue
>        0    0    0 5.630359813726E-02 0.000000000000E+00
>        0    0   -1-1.150778984163E-02 8.051431134897E-03
>        0    0    1-1.150778984163E-02-8.051431134897E-03
>        0    0   -2-9.470078634937E-04 1.160395119838E-02
>        0    0    2-9.470078634937E-04-1.160395119838E-02
>        0    0   -3 3.822712367509E-03 5.400713534390E-03
>        0    0    3 3.822712367509E-03-5.400713534390E-03
>        0    0   -4 2.813831811510E-03 4.780854323303E-04
>        0    0    4 2.813831811510E-03-4.780854323303E-04
>        0    0   -5-1.336690365246E-03 4.849945762786E-04
>
> > Otherwise more with the struct file.
> >
> > Is this still ok ? Can you run   x nn    with this struct file ?
>
> ‘x nn’ is fine, in fact, the whole SCF cycle is fine up to mixer.
>
> I checked all files in the directory for NaN's, there are none.
>
>
>         Elias
>
>
> --
> Elias Assmann
> Institute of Theoretical and Computational Physics
> TU Graz                   ⟨https://itp.tugraz.at/⟩
>
>


-- 
Professor Laurence Marks
Department of Materials Science and Engineering
Northwestern University
www.numis.northwestern.edu
Corrosion in 4D: MURI4D.numis.northwestern.edu
Co-Editor, Acta Cryst A
"Research is to see what everybody else has seen, and to think what nobody
else has thought"
Albert Szent-Gyorgi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20151111/a40f227f/attachment.html>