[Wien] LAPW0 hangs in mBJ calculation

Wed Dec 15 09:14:40 CET 2010

Hi Dr. Blaha,

I did read through the mailing list. As per earlier suggestions, I was 
using a modified brj.f routine (sent out by Dr. Jalali on October 25th, 
2010 in response to problems with the large rho in heavy elements and 
small rho in light light elements, in this post: 
http://zeus.theochem.tuwien.ac.at/pipermail/wien/2010-October/013886.html), 
attached. (I don't know if this is the most recent brj.f routine though.)

Anyway it seems that the new (as of 25/10/2010) brj.f is causing the 
problems. It seems I inadvertently ran the spin-polarized calculation 
using the old (the one with the original WIEN2k_10.1) brj.f file.

Sorry for not checking this before posting to the mailing list.

Anyway, now LAPW0 hangs with both HgO and PbO using the newer brj.f 
routine, while the calculations converge properly with the old brj.f 
routine - so it seems pretty clear that the problem is with heavy elements.

Now I am confused: I thought the updated brj.f routine was supposed to 
handle heavy elements better than the old brj.f routine. Should I roll 
back to the original brj.f routine, or is there a more recently updated 
version I should use?

(I did search the mailing list but the most recent post mentioning 
"brj.f" was from October 30th)

Thanks again,
John McLeod

Ph.D. candidate,
Department of Physics and Engineering Physics,
University of Saskatchewan

On 12/14/2010 11:59 PM, Peter Blaha wrote:
> Did you check the mailinglist postings ? Similar reports were made 
> several weeks ago
> and modifications of the mbj routines were posted. Are you using the 
> modified routines
> or the original ones from WIEN2k_10 ??
>
> Am 14.12.2010 23:28, schrieb John McLeod:
>> Hello WIEN2k users,
>>
>> I am running version 10.1 on a quad core x86_64 architecture with 
>> Intel 11.1.072 IFC and MKL.
>> I was calculating the DOS for a variety of binary oxides, and I ran 
>> into a problem with HgO.
>>
>> For the attached .struct file, a GGA calculation (PBE96, with all 
>> default parameters: -6 Ry cutoff, 1000 k-points, non-spin 
>> calculation) converges quickly and the results
>> look reasonable.
>>
>> For the mBJ calculation, the single .in0 (NR2V --> R2V) and 
>> .inm_vresp calculation cycle finishes quickly. For the full mBJ cycle 
>> (with xc = 28 in .in0, xc = 50 in
>> .in0_grr, and 0.2 PRATT mixing in .inm) the first LAPW0 cycle (lapw0 
>> -grr) finishes quickly but the main LAPW0 cycle seems to freeze (it 
>> did not complete after 14 hours).
>> Below is the day file. I suppose the `tauwrong' parameter is an 
>> indication of what the error is.
>>
>> This problem was persistent after restarting the calculation with 
>> different parameters (in1new, non-parallel, etc.) and on different 
>> computer systems. I did not, however,
>> try adjusting RMTs, k-points, or the core/semi-core cutoff.
>>
>> Anyway, when I started from scratch with a spin-polarized calculation 
>> of HgO (PBE96, all other parameters default) the mBJ extension 
>> converges after several cycles at 0.5
>> PRATT mixing. Looking at the DOS, the spin up and spin down states 
>> are identical (as I would expect).
>>
>> A non-spin polarized PBE96+mBJ calculation converges for the related 
>> oxides CdO, PbO, and Au2O3 (with the appropriate crystal structures). 
>> If I switch the Hg for Pb in the
>> attached struct file (creating a fictitious phase of PbO) the 
>> non-spin polarized PBE96+mBJ calculation converges. Further, if I 
>> switch Pb for Hg in litharge-phase PbO
>> (creating a fictitious phase of HgO) the calculation converges.
>>
>> I am curious if anyone has any insight into what is going on here.
>>
>> I am happy with the spin polarized calculation, but would like to 
>> figure out why the spin polarized calculation worked while the 
>> regular calculation did not.
>>
>> Thanks,
>> John McLeod
>>
>> Ph.D. candidate,
>> Department of Physics and Engineering Physics,
>> University of Saskatchewan
>>
>> ---------------- case.dayfile start ----------------
>> using WIEN2k_10.1 (Release 7/6/2010) in /usr/local/share/WIEN2k/10.1
>> start (Mon Dec 13 11:40:15 CST 2010) with lapw0 (40/99 to go)
>>
>> cycle 1 (Mon Dec 13 11:40:15 CST 2010) (40/99 to go)
>>
>> > lapw0 -grr -p (11:40:15) starting parallel lapw0 at Mon Dec 13 
>> 11:40:15 CST 2010
>> -------- .machine0 : processors
>> running lapw0 in single mode
>> 2.235u 0.262s 0:02.49 100.0% 0+0k 0+8624io 0pf+0w
>> > lapw0 -p (11:40:18) starting parallel lapw0 at Mon Dec 13 11:40:18 
>> CST 2010
>> -------- .machine0 : processors
>> running lapw0 in single mode
>> int:rho,tauw,grho,g2rho 3906392.62874521 5.552066580361303E+015
>> 294540672667.298 -3.693753715914154E+016 tauwrong=
>> -1.834378635950119E+016
>> [snip: more lines of "int:rho,..." as above]
>> int:rho,tauw,grho,g2rho 3906392.62878114 5.552066580175691E+015
>> 294540672663.729 -3.693753716133459E+016 tauwrong=
>> -1.834378636059656E+016
>> ---------------- case.dayfile end ----------------
>>
>>
>>
>> _______________________________________________
>> Wien mailing list
>> Wien at zeus.theochem.tuwien.ac.at
>> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: brj.f
Type: text/x-fortran
Size: 3650 bytes
Desc: not available
URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20101215/5984df4d/attachment.f>