[Wien] Possible error in LAPW2 code

[McLeod, John]

Hello WIEN2k users,

In regards to my last email I just realized that all the other loops over the lattice vectors (lines 805, 817) have the condition
  IF(myid_vec*ibpp*iblock+i.GT.n-(nlo+nlon+nlov)) EXIT
I.e. the same condition as in line 747 but without the extra '-1' on the left hand side of the inequality.

This means that any "fake" lattice vectors created at the end of BK() will be ignored by the rest of the program.

So I guess there isn't any issue with the code after all, and I guess I understand where the relevant vectors come from.

Sorry for the trouble,
John 

On 2012-12-01, at 5:03 PM, McLeod, John wrote:

> Hello WIEN2k users,
> 
> I am using WIEN2k version 11.1. In L2MAIN.F line 747 reads:
>    IF(myid_vec*ibpp*iblock+i-1.GT.n-(nlo+nlon+nlov)) EXIT
> If I understand what this part of the code is doing properly, I think it should be a .GE. condition rather than a .GT. condition.
> 
> To explain my line of thinking:
> 
> I have been reading through the LAPW2 code to help me understand how the (L)APW+LO+lo basis is generated. I was looking at the rotated G + k vectors (in L2MAIN.F the BK, BKROT, BKRLOC vectors), and modified the code for L2MAIN.F slightly to print each vector to the screen after it was rotated by the appropriate matrix (ROTIJ, BR1, ROTLOC).
> 
> However because of the above .GT. condition there are n - (nlo+nlon+nlov) + 1 vectors generated. (In serial mode, at least, when myid_vec = 0.)
> 
> This is a problem, I think, because in READ_VEC.F there are only n - (nlo+nlon+nlov) vectors defined.
> 
> In my test case (fcc MgO, run in serial mode) the gamma point had the most vectors (126 G-vectors in case.vector total, 13 of them are LOs) and L2MAIN went through the i=ii,ii+iblock-1 loop (line 746) 114 times, and the last vector used had some enormous and random-looking components.
> 
> I do not think the relevant arrays (the KX(), KY(), KZ() arrays) are ever fully initialized (to zero, at least), so it makes sense to me that if only 113 G+k values are determined in READ_VEC.F that the 114th should be gibberish.
> 
> I did change the condition in L2MAIN.F at line 747 to a .GE., recompiled, and ran an SCF cycle on my test case again, the change was very small (one part in a thousand or smaller).
> 
> If the .GT. is not an error, then I clearly do not understand something about how these G + k vectors are determined.
> 
> Regards,
> John
> 
> ---------------
> To illustrate what I mean, I added this code just after line 752 in L2MAIN.F
> 	write(*,*) 'atom',jatom,'site',mu,'kpt',kkk,'vec',i
> 	write(*,*) (bk(itmp),itmp=1,3)
> 
> The last three bk vectors for the gamma point were:
> atom           1 site           1 kpt           1 vec         112
>   4.00000000000000       0.000000000000000E+000   2.00000000000000     
> atom           1 site           1 kpt           1 vec         113
>  0.000000000000000E+000   4.00000000000000        2.00000000000000     
> atom           1 site           1 kpt           1 vec         114
>  0.000000000000000E+000   807411763.000000       0.000000000000000E+000
> 
> I think the vector 114 should not be present, and should not have a ky-component of eight hundred million.
> 
> 
> _______________________________________________
> Wien mailing list
> Wien at zeus.theochem.tuwien.ac.at
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien