[Wien] AIX PBE(?) error
Oliver Albertini
ora at georgetown.edu
Wed Apr 3 17:24:55 CEST 2013
Dear Wien2k users,
The problem on AIX was that in the file SRC_lapw0/xcpot3.F there is a line
CALL PWXAD4(IFFT1,IFFT2,IFFT3_g,TVEC,AM)
The IFFT3_g goes into the call as a non-zero integer, but since it is
declared as
integer(C_INTPTR_T) :: ifft3_g in fft_modules.F, I believe AIX does
something strange and in the routine pwxad4 it becomes a zero, with many
NaNs as a result.
So the general solution as suggested by Dr. Blaha is to declare a new
integer in xcpot3.F called IFFT3_g1
then replace the above call with
IFFT3_g1=IFFT3_g
CALL PWXAD4(IFFT1,IFFT2,IFFT3_g1,TVEC,AM)
This works for me.
Sincerely,
Oliver Albertini
On Wed, Apr 3, 2013 at 5:57 AM, Luis Ogando <lcodacal at gmail.com> wrote:
> 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>
>>
>
>
> _______________________________________________
> Wien mailing list
> Wien at zeus.theochem.tuwien.ac.at
> 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/97798694/attachment-0001.htm>
More information about the Wien
mailing list