[Wien] AIX PBE(?) error
Oliver Albertini
ora at georgetown.edu
Fri Mar 29 20:39:58 CET 2013
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>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.
>> "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 <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/20130329/2adce064/attachment.htm>
More information about the Wien
mailing list