[Wien] AIX PBE(?) error
Luis Ogando
lcodacal at gmail.com
Wed Apr 3 14:57:17 CEST 2013
Dear Prof. Blaha, Albertini and Wien2k community,
I am facing the same problem described by Prof. Albertine (in a
IBM/AIX/XLF system, LSDA calculations go without error, but PBE ones fail).
I am obviously very interested in solving this. If you have any news,
please comment. If you need any information, please ask.
All the best,
Luis
2013/3/29 Peter Blaha <pblaha at theochem.tuwien.ac.at>
> Seems to be a problem in lapw0 and the interstital XC-potential.
>
> Could be due to the FFT-routines (but LDA works ??), otherwise it seems
> that
> the gradients are not calculated properly.
>
> Are you using -DFFTW2 or 3 or the default fftpack routines ?
>
> Probably one has to put some printing-debug statements into xcpot3 or
> vxclm2 or pwxad4/5.f
>
> Am 29.03.2013 20:39, schrieb Oliver Albertini:
>
>> The case.vsp file looks similar for both (similar magnitudes). The PBE
>> case.output0 file has a lot of NaN:
>>
>> SELECTED FOURIERCOEFF. OF V-XC
>> 0 0 0 NaNQ 0.00000E+00 NaNQ
>> 0.00000E+00
>> 0 0 1 NaNQ NaNQ NaNQ
>> NaNQ
>> 0 0 2 NaNQ NaNQ NaNQ
>> NaNQ
>> 0 0 3 NaNQ NaNQ NaNQ
>> NaNQ
>> 0 0 4 NaNQ NaNQ NaNQ
>> NaNQ
>> 0 0 5 NaNQ NaNQ NaNQ
>> NaNQ
>> 0 0 6 NaNQ NaNQ NaNQ
>> NaNQ
>> 0 0 7 NaNQ NaNQ NaNQ
>> NaNQ
>> 0 0 8 NaNQ NaNQ NaNQ
>> NaNQ
>> 0 0 9 NaNQ NaNQ NaNQ
>> NaNQ
>> 0 0 10 NaNQ NaNQ NaNQ
>> NaNQ
>> 0 0 11 NaNQ NaNQ NaNQ
>> NaNQ
>> 0 0 12 NaNQ NaNQ NaNQ
>> NaNQ
>> 0 0 13 NaNQ NaNQ NaNQ
>> NaNQ
>> 0 0 14 NaNQ NaNQ NaNQ
>> NaNQ
>> 0 0 15 NaNQ NaNQ NaNQ
>> NaNQ
>> 0 0 16 NaNQ NaNQ NaNQ
>> NaNQ
>> 0 0 17 NaNQ NaNQ NaNQ
>> NaNQ
>> 0 0 18 NaNQ NaNQ NaNQ
>> NaNQ
>> 0 0 19 NaNQ NaNQ NaNQ
>> NaNQ
>> 0 0 20 NaNQ NaNQ NaNQ
>> NaNQ
>> 0 0 21 NaNQ NaNQ NaNQ
>> NaNQ
>> 0 0 22 NaNQ NaNQ NaNQ
>> NaNQ
>> 0 0 23 NaNQ NaNQ NaNQ
>> NaNQ
>> 0 0 24 NaNQ NaNQ NaNQ
>> NaNQ
>>
>> The case.output1 files again seem similar, but for PBE, it has NaN under
>> "WARPING="
>>
>>
>> On Fri, Mar 29, 2013 at 12:12 PM, Peter Blaha <
>> pblaha at theochem.tuwien.ac.at <mailto:pblaha at theochem.**tuwien.ac.at<pblaha at theochem.tuwien.ac.at>>>
>> wrote:
>>
>> If LDA works, but PBE does not, the problem must be in lapw0.
>>
>> Compare case.output0 (and case.vsp) after two x lapw0
>> runs, one with LDA, the other with PBE.
>> The files must be "similar", but I expect some severe differences,
>> since you seem to get no eigenvalues in case.output1 (again compare
>> these
>> file in an lda-gga calculation.)
>>
>> Am 29.03.2013 18:14, schrieb Oliver Albertini:
>>
>> Hello,
>>
>> After running some successful cases for NiO, I tried to run the
>> Userguide example of TiC. I set it up according to the guide.
>>
>> # run_lapw
>> hup: Command not found.
>> STOP LAPW0 END
>> STOP LAPW1 END
>> "fermi_tmp_.F", line 516: 1525-097 A READ statement using decimal
>> base input found the invalid digit '.' in the input file. The program will
>> recover by assuming a
>> zero in
>> its place.
>> "fermi_tmp_.F", line 516: 1525-097 A READ statement using decimal
>> base input found the invalid digit 'E' in the input file. The program will
>> recover by assuming a
>> zero in
>> its place.
>> "fermi_tmp_.F", line 516: 1525-097 A READ statement using decimal
>> base input found the invalid digit '-' in the input file. The program will
>> recover by assuming a
>> zero in
>> its place.
>> "fermi_tmp_.F", line 516: 1525-096 A data item processed during
>> an integer read is too large. The program will recover by assigning the
>> data item the value
>> 2147483647 <tel:2147483647>.
>>
>> "fermi_tmp_.F", line 516: 1525-097 A READ statement using decimal
>> base input found the invalid digit '-' in the input file. The program will
>> recover by assuming a
>> zero in
>> its place.
>> "fermi_tmp_.F", line 516: 1525-097 A READ statement using decimal
>> base input found the invalid digit '.' in the input file. The program will
>> recover by assuming a
>> zero in
>> its place.
>> "fermi_tmp_.F", line 516: 1525-097 A READ statement using decimal
>> base input found the invalid digit 'E' in the input file. The program will
>> recover by assuming a
>> zero in
>> its place.
>> "fermi_tmp_.F", line 516: 1525-097 A READ statement using decimal
>> base input found the invalid digit '-' in the input file. The program will
>> recover by assuming a
>> zero in
>> its place.
>>
>> > stop error
>>
>> I determined that the read file is TiC.energy.
>>
>> Here is the TiC.energy file. It seems to not have any
>> eigenvalues, only kpoints. Compared to the TiC.energy in the examples
>> directory, it seems wrong. The read
>> statement is
>> expecting an int then a dble, but instead gets another kpoint. Is
>> there any way to track down where things are going wrong?
>>
>> 200.30000198.43117200.42221 0.30000 0.30000 0.30000 0.30000
>> 0.30000 0.30000 0.30000 0.30000 0.30000 0.30000 0.00000
>> 0.30000 -1.56883 0.42221999.00000 -3.29057
>> 0.30000997.00000999.00000999._**_00000999.00000999.00000999.__**00000
>>
>> 199.22000200.30000 0.30000 0.30000 0.30000 0.30000 0.30000
>> 0.30000 0.30000 0.30000 0.30000 0.30000 0.30000 0.00000
>> -0.78000 0.30000999.00000999.00000
>> 0.30000997.00000999.00000999._**_00000999.00000999.00000999.__**
>> 00000999.00000
>>
>> 0.000000000000E+00 0.000000000000E+00 0.000000000000E+00
>> 1 155 0 1.0
>> 1.000000000000E-01 1.000000000000E-01-1.__**000000000000E-01
>> 2 146 0 8.0
>> 2.000000000000E-01 2.000000000000E-01-2.__**000000000000E-01
>> 3 147 0 8.0
>> 3.000000000000E-01 3.000000000000E-01-3.__**000000000000E-01
>> 4 144 0 8.0
>> 4.000000000000E-01 4.000000000000E-01-4.__**000000000000E-01
>> 5 141 0 8.0
>> 5.000000000000E-01 5.000000000000E-01-5.__**000000000000E-01
>> 6 138 0 4.0
>>
>> 2.000000000000E-01 0.000000000000E+00 0.000000000000E+00
>> 7 143 0 6.0
>> 3.000000000000E-01 1.000000000000E-01-1.__**000000000000E-01
>> 8 149 0 24.0
>> 4.000000000000E-01 2.000000000000E-01-2.__**000000000000E-01
>> 9 150 0 24.0
>> 5.000000000000E-01 3.000000000000E-01-3.__**000000000000E-01
>> 10 146 0 24.0
>> 6.000000000000E-01 4.000000000000E-01-4.__**000000000000E-01
>> 11 145 0 24.0
>> 7.000000000000E-01 5.000000000000E-01-5.__**000000000000E-01
>> 12 144 0 24.0
>> 8.000000000000E-01 6.000000000000E-01-6.__**000000000000E-01
>> 13 147 0 24.0
>> 9.000000000000E-01 7.000000000000E-01-7.__**000000000000E-01
>> 14 149 0 24.0
>> 1.000000000000E+00 8.000000000000E-01-8.__**000000000000E-01
>> 15 145 0 12.0
>>
>> 4.000000000000E-01 0.000000000000E+00 0.000000000000E+00
>> 16 147 0 6.0
>> 5.000000000000E-01 1.000000000000E-01-1.__**000000000000E-01
>> 17 146 0 24.0
>> 6.000000000000E-01 2.000000000000E-01-2.__**000000000000E-01
>> 18 142 0 24.0
>> 7.000000000000E-01 3.000000000000E-01-3.__**000000000000E-01
>> 19 141 0 24.0
>> 8.000000000000E-01 4.000000000000E-01-4.__**000000000000E-01
>> 20 143 0 24.0
>> 9.000000000000E-01 5.000000000000E-01-5.__**000000000000E-01
>> 21 147 0 24.0
>> 1.000000000000E+00 6.000000000000E-01-6.__**000000000000E-01
>> 22 149 0 12.0
>>
>> 6.000000000000E-01 0.000000000000E+00 0.000000000000E+00
>> 23 147 0 6.0
>> 7.000000000000E-01 1.000000000000E-01-1.__**000000000000E-01
>> 24 144 0 24.0
>> 8.000000000000E-01 2.000000000000E-01-2.__**000000000000E-01
>> 25 142 0 24.0
>>
>> etc...
>>
>> It is interesting to note that when I run the same case with
>> LSDA, it works.
>> Also when I run NiO (which I previously did with LSDA) using PBE,
>> the following error appears:
>>
>> "fermi_tmp_.F", line 516: 1525-001 The READ statement on the file
>> 12_NiO.energyup cannot be completed because the end of the file was
>> reached. The program will stop.
>> Thanks,
>>
>> Oliver
>>
>>
>> ______________________________**___________________
>> Wien mailing list
>> Wien at zeus.theochem.tuwien.ac._**_at <mailto:Wien at zeus.theochem.**
>> tuwien.ac.at <Wien at zeus.theochem.tuwien.ac.at>>
>> http://zeus.theochem.tuwien.__**ac.at/mailman/listinfo/wien<http://ac.at/mailman/listinfo/wien><
>> http://zeus.theochem.tuwien.**ac.at/mailman/listinfo/wien<http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien>
>> >
>>
>>
>> --
>> ------------------------------**__-----------
>>
>> Peter Blaha
>> Inst. Materials Chemistry, TU Vienna
>> Getreidemarkt 9, A-1060 Vienna, Austria
>> Tel: +43-1-5880115671 <tel:%2B43-1-5880115671>
>> Fax: +43-1-5880115698 <tel:%2B43-1-5880115698>
>> email: pblaha at theochem.tuwien.ac.at <mailto:pblaha at theochem.**
>> tuwien.ac.at <pblaha at theochem.tuwien.ac.at>>
>> ------------------------------**__-----------
>> ______________________________**___________________
>> Wien mailing list
>> Wien at zeus.theochem.tuwien.ac._**_at <mailto:Wien at zeus.theochem.**
>> tuwien.ac.at <Wien at zeus.theochem.tuwien.ac.at>>
>> http://zeus.theochem.tuwien.__**ac.at/mailman/listinfo/wien<http://ac.at/mailman/listinfo/wien><
>> http://zeus.theochem.tuwien.**ac.at/mailman/listinfo/wien<http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien>
>> >
>>
>>
>>
>>
>>
>> ______________________________**_________________
>> Wien mailing list
>> Wien at zeus.theochem.tuwien.ac.**at <Wien at zeus.theochem.tuwien.ac.at>
>> http://zeus.theochem.tuwien.**ac.at/mailman/listinfo/wien<http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien>
>>
>>
> --
> ------------------------------**-----------
> Peter Blaha
> Inst. Materials Chemistry, TU Vienna
> Getreidemarkt 9, A-1060 Vienna, Austria
> Tel: +43-1-5880115671
> Fax: +43-1-5880115698
> email: pblaha at theochem.tuwien.ac.at
> ------------------------------**-----------
> ______________________________**_________________
> Wien mailing list
> Wien at zeus.theochem.tuwien.ac.**at <Wien at zeus.theochem.tuwien.ac.at>
> http://zeus.theochem.tuwien.**ac.at/mailman/listinfo/wien<http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20130403/a96f9284/attachment.htm>
More information about the Wien
mailing list