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.assm...@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
_______________________________________________ Wien mailing list Wien@zeus.theochem.tuwien.ac.at http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien SEARCH the MAILING-LIST at: http://email@example.com/index.html