subject:"\[Wien\] segfault in mixer"

Re: [Wien] segfault in mixer

2015-11-11 Thread Elias Assmann

On 11/11/2015 03:40 PM, Laurence Marks wrote:
> 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.

I think you are right, and I think I localized the problem.  EMIN in
case.in2 was set too large (0.53 to be precise).  Thus in case.output2
the band energies were reasonable, but the occupations were all zero.  I
have to wait for my batch job to start, but this looks promising.

The EMIN was probably a leftover from a charge distribution calculation.

Thanks for the help!

Elias

-- 
Elias Assmann
Institute of Theoretical and Computational Physics
TU Graz   ⟨https://itp.tugraz.at/⟩



signature.asc
Description: OpenPGP digital signature
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

Re: [Wien] segfault in mixer

2015-11-11 Thread Elias Assmann

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/11/2015 04:04 PM, Zhu, Jianxin wrote:
> I am curios. How come the value emin becomes so big? It is
> automatically set, no.

I think I set it when I was calculating a charge density (to get only
the “valence” density).  When I picked the calculation up again, I
forgot to change it back.

Elias


> The EMIN was probably a leftover from a charge distribution
> calculation.


-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBAgAGBQJWQ1s6AAoJEE/4gtQZfOqPKXUQAKF8yBlnXybrBcqOFkO5swxU
YoVvRaSHXFjvqoKVvdRAQyX6XyCQq+croO0TeMllMms2jGQ75Orwt1hPj0mY5fgS
pJ/8TnXDqWM7kI9fCbb/ImlXnVNazzLN4NfHKXXAK9Zh5SF/bg2JY1sWb1I3NQVD
ifvTCr8wkSkPx4w4OgHAB11SbXYQUvx3l4U2KQ42DNVRUvNpI1+SQeLOg8iTmeuJ
OGeH2XDHerfEtRL4inY67hK7y/MK8QXvo9mGRtFoxOg9CvLXkPt4kBY+E7yDRcLW
tYF2n2BjhHd12vtaSwy+ZEppACbEspUMrkoM5lKRcu2V/fUtYYfXNrnpuqAd4Byj
RGnfDSSZK+BqfvineuhZx1VxV7lCw9A4WFClV0u5UNkmqFHDpEA2uM45WAPyi9Fo
KIamOaVKDtrOmKU/FhnbRZHQ3JbOWUVphP4QdHyxBkC/a+n95lb5iqKHP21YUtbp
v4q4O5ZUQW4DBNJLeuzGwNMbnyWYap1E1oFnrdG5Mqvqtmk6J+nin1BXA00qmmty
qtaXpuOrpk111OAKNYoWwfApatomD90f/gZ9tC901AdmUbbpjpjiVZYGkpQxdIPD
jz4WoRhYd95y0/r/s/Xy0Vi7yaAFxonAeEgN98Ybea181PXshVAWgU2O8BEpG35u
0xTwhiZEaRzAEnXV2xKd
=ZsIi
-END PGP SIGNATURE-
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

Re: [Wien] segfault in mixer

2015-11-11 Thread Zhu, Jianxin

I am curios. How come the value emin becomes so big? It is automatically set, 
no.

Jianxin

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
  Original Message
From: Elias Assmann
Sent: Wednesday, November 11, 2015 8:53 AM
To: A Mailing list for WIEN2k users
Reply To: A Mailing list for WIEN2k users
Subject: Re: [Wien] segfault in mixer

On 11/11/2015 03:40 PM, Laurence Marks wrote:
> 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.

I think you are right, and I think I localized the problem.  EMIN in
case.in2 was set too large (0.53 to be precise).  Thus in case.output2
the band energies were reasonable, but the occupations were all zero.  I
have to wait for my batch job to start, but this looks promising.

The EMIN was probably a leftover from a charge distribution calculation.

Thanks for the help!

Elias

--
Elias Assmann
Institute of Theoretical and Computational Physics
TU Graz   ⟨https://itp.tugraz.at/⟩

___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

Re: [Wien] segfault in mixer

2015-11-11 Thread Peter Blaha


Never had such a problem.

Anything in case.outputm ?

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


Otherwise more with the struct file.

Is this still ok ? Can you run   x nnwith this struct file ?



On 11/11/2015 02:43 PM, Elias Assmann wrote:

Hi List,

In a fairly large calculation (200 atoms) I am running I get a segfault
in mixer:

$ x mixer
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image   RoutineLineSource
mixer   Unknown   Unknown  Unknown
mixer   Unknown   Unknown  Unknown
mixer   Unknown   Unknown  Unknown
mixer   Unknown   Unknown  Unknown
mixer   Unknown   Unknown  Unknown
libpthread.so.0 Unknown   Unknown  Unknown
mixer   setn_  27  setn.f
mixer   MAIN__   1232  mixer.F
mixer   Unknown   Unknown  Unknown
libc.so.6   Unknown   Unknown  Unknown
mixer   Unknown   Unknown  Unknown

Line 27 in setn.f is just

   FFT(1)=U0

the ‘FFT’ array corresponds to ‘cfft’ in mixer.F, and indeed

$ tail STO6LVO2_ovac.outputm
…
  Allocating CLM-arrays  678  MB
  Allocating nwav-arrays  57  MB
  Allocating cfft-array0  MB

Any idea where this might come from?  I strongly suspect some error in
the input because another, similar, calculation is running without this
problem; but I have no idea what I might have changed to cause the error.

Here is my case.inm:

MSR1   0.0   YES  (BROYD/PRATT, extra charge (+1 for additional e), norm)
0.20mixing FACTOR for BROYD/PRATT scheme
1.00  1.00  PW and CLM-scaling factors
  8 idum, HISTORY

The error keeps happening even after I removed case.broyd*.


Elias




___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html



--

  P.Blaha
--
Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
Phone: +43-1-58801-165300 FAX: +43-1-58801-165982
Email: bl...@theochem.tuwien.ac.atWIEN2k: http://www.wien2k.at
WWW:   http://www.imc.tuwien.ac.at/staff/tc_group_e.php
--
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

Re: [Wien] segfault in mixer

2015-11-11 Thread Elias Assmann

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
   000 0.E+00 0.E+00
   00   -1 0.E+00 0.E+00
   001 0.E+00 0.E+00
   00   -2 0.E+00 0.E+00
   002 0.E+00 0.E+00
   00   -3 0.E+00 0.E+00
   003 0.E+00 0.E+00
   00   -4 0.E+00 0.E+00
   004 0.E+00 0.E+00
   00   -5 0.E+00 0.E+00

$ grep -e PW *.clmsum -A10
 594657 NUMBER OF PW Change
Residue
   000 5.630359813726E-02 0.E+00
   00   -1-1.150778984163E-02 8.051431134897E-03
   001-1.150778984163E-02-8.051431134897E-03
   00   -2-9.470078634937E-04 1.160395119838E-02
   002-9.470078634937E-04-1.160395119838E-02
   00   -3 3.822712367509E-03 5.400713534390E-03
   003 3.822712367509E-03-5.400713534390E-03
   00   -4 2.813831811510E-03 4.780854323303E-04
   004 2.813831811510E-03-4.780854323303E-04
   00   -5-1.336690365246E-03 4.849945762786E-04

> Otherwise more with the struct file.
> 
> Is this still ok ? Can you run   x nnwith 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/⟩



signature.asc
Description: OpenPGP digital signature
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

Re: [Wien] segfault in mixer

2015-11-11 Thread Laurence Marks

I agree with Peter. A problem with SIGSEGV is that the line it indicates is
often not where the problem actually is. My guess would be that there is
something wrong with the struct format, and/or you have no PW's. For the
later try

grep -e PW case.clmval(up/dn) -A10

(change case etc)

and see if there are NAN's present.

On Wed, Nov 11, 2015 at 7:53 AM, Peter Blaha 
wrote:

> Never had such a problem.
>
> Anything in case.outputm ?
>
> 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
>
> Otherwise more with the struct file.
>
> Is this still ok ? Can you run   x nnwith this struct file ?
>
>
>
> On 11/11/2015 02:43 PM, Elias Assmann wrote:
> > Hi List,
> >
> > In a fairly large calculation (200 atoms) I am running I get a segfault
> > in mixer:
> >
> > $ x mixer
> > forrtl: severe (174): SIGSEGV, segmentation fault occurred
> > Image   RoutineLineSource
> > mixer   Unknown   Unknown  Unknown
> > mixer   Unknown   Unknown  Unknown
> > mixer   Unknown   Unknown  Unknown
> > mixer   Unknown   Unknown  Unknown
> > mixer   Unknown   Unknown  Unknown
> > libpthread.so.0 Unknown   Unknown  Unknown
> > mixer   setn_  27  setn.f
> > mixer   MAIN__   1232  mixer.F
> > mixer   Unknown   Unknown  Unknown
> > libc.so.6   Unknown   Unknown  Unknown
> > mixer   Unknown   Unknown  Unknown
> >
> > Line 27 in setn.f is just
> >
> >FFT(1)=U0
> >
> > the ‘FFT’ array corresponds to ‘cfft’ in mixer.F, and indeed
> >
> > $ tail STO6LVO2_ovac.outputm
> > …
> >   Allocating CLM-arrays  678  MB
> >   Allocating nwav-arrays  57  MB
> >   Allocating cfft-array0  MB
> >
> > Any idea where this might come from?  I strongly suspect some error in
> > the input because another, similar, calculation is running without this
> > problem; but I have no idea what I might have changed to cause the error.
> >
> > Here is my case.inm:
> >
> > MSR1   0.0   YES  (BROYD/PRATT, extra charge (+1 for additional e), norm)
> > 0.20mixing FACTOR for BROYD/PRATT scheme
> > 1.00  1.00  PW and CLM-scaling factors
> >   8 idum, HISTORY
> >
> > The error keeps happening even after I removed case.broyd*.
> >
> >
> >   Elias
> >
> >
> >
> >
> > ___
> > Wien mailing list
> > Wien@zeus.theochem.tuwien.ac.at
> > http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
> > SEARCH the MAILING-LIST at:
> http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
> >
>
> --
>
>P.Blaha
> --
> Peter BLAHA, Inst.f. Materials Chemistry, TU Vienna, A-1060 Vienna
> Phone: +43-1-58801-165300 FAX: +43-1-58801-165982
> Email: bl...@theochem.tuwien.ac.atWIEN2k: http://www.wien2k.at
> WWW:   http://www.imc.tuwien.ac.at/staff/tc_group_e.php
> --
> ___
> Wien mailing list
> Wien@zeus.theochem.tuwien.ac.at
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
> SEARCH the MAILING-LIST at:
> http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
>



-- 
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://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

[Wien] segfault in mixer

2015-11-11 Thread Elias Assmann

Hi List,

In a fairly large calculation (200 atoms) I am running I get a segfault
in mixer:

$ x mixer
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image   RoutineLineSource
mixer   Unknown   Unknown  Unknown
mixer   Unknown   Unknown  Unknown
mixer   Unknown   Unknown  Unknown
mixer   Unknown   Unknown  Unknown
mixer   Unknown   Unknown  Unknown
libpthread.so.0 Unknown   Unknown  Unknown
mixer   setn_  27  setn.f
mixer   MAIN__   1232  mixer.F
mixer   Unknown   Unknown  Unknown
libc.so.6   Unknown   Unknown  Unknown
mixer   Unknown   Unknown  Unknown

Line 27 in setn.f is just

  FFT(1)=U0

the ‘FFT’ array corresponds to ‘cfft’ in mixer.F, and indeed

$ tail STO6LVO2_ovac.outputm
…
 Allocating CLM-arrays  678  MB
 Allocating nwav-arrays  57  MB
 Allocating cfft-array0  MB

Any idea where this might come from?  I strongly suspect some error in
the input because another, similar, calculation is running without this
problem; but I have no idea what I might have changed to cause the error.

Here is my case.inm:

MSR1   0.0   YES  (BROYD/PRATT, extra charge (+1 for additional e), norm)
0.20mixing FACTOR for BROYD/PRATT scheme
1.00  1.00  PW and CLM-scaling factors
  8 idum, HISTORY

The error keeps happening even after I removed case.broyd*.


Elias


-- 
Elias Assmann
Institute of Theoretical and Computational Physics
TU Graz   ⟨https://itp.tugraz.at/⟩



signature.asc
Description: OpenPGP digital signature
___
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

Re: [Wien] segfault in mixer

2015-11-11 Thread 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 
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
>000 0.E+00 0.E+00
>00   -1 0.E+00 0.E+00
>001 0.E+00 0.E+00
>00   -2 0.E+00 0.E+00
>002 0.E+00 0.E+00
>00   -3 0.E+00 0.E+00
>003 0.E+00 0.E+00
>00   -4 0.E+00 0.E+00
>004 0.E+00 0.E+00
>00   -5 0.E+00 0.E+00
>
> $ grep -e PW *.clmsum -A10
>  594657 NUMBER OF PW Change
> Residue
>000 5.630359813726E-02 0.E+00
>00   -1-1.150778984163E-02 8.051431134897E-03
>001-1.150778984163E-02-8.051431134897E-03
>00   -2-9.470078634937E-04 1.160395119838E-02
>002-9.470078634937E-04-1.160395119838E-02
>00   -3 3.822712367509E-03 5.400713534390E-03
>003 3.822712367509E-03-5.400713534390E-03
>00   -4 2.813831811510E-03 4.780854323303E-04
>004 2.813831811510E-03-4.780854323303E-04
>00   -5-1.336690365246E-03 4.849945762786E-04
>
> > Otherwise more with the struct file.
> >
> > Is this still ok ? Can you run   x nnwith 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://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

Re: [Wien] segfault in mixer

Re: [Wien] segfault in mixer

Re: [Wien] segfault in mixer

Re: [Wien] segfault in mixer

Re: [Wien] segfault in mixer

Re: [Wien] segfault in mixer

[Wien] segfault in mixer

Re: [Wien] segfault in mixer

8 matches

Site Navigation

Mail list logo

Footer information