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 ---------------- -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: HgO.struct URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20101214/5ed5a7b1/attachment.bat>