The ABINIT Users Mailing List ( CLOSED )

[Valerio Olevano <valerio.olevano@polytechnique.fr>]

Dear Vadim,

> One more question: why does the presence of non-symmorphic operations
> in the symmetries list cause problems? Does it cause wrong
> wavefunctions in _STA (or _KSS) file to be produced?

no, it doesn't. the kss file is good, but as gianmarco told,
the gw code is unable to consider translations in symmetries.

> I have questions related to GW calculations, especially to sig.
>
> The first is implementation of the case where k-k' is out of Brillouin 
> zone, and special G0 vector is needed. (Is it called umklapp?) How is 
> this case treated in the sig program? Also, how does the rho_tw_g 
> module work, does it calculate matrix elements for Phi(n,k) and 
> Phi(n1,k1) such that k-k1 is out of BZ, correctly?

You answered by yourself in your 3rd question:

> What role does the variable igfftg0 play in the module rho_tw_g? It 
> seems that you tried (maybe successfully) to implement the real-space 
> calculation of the matrix element <wfr|exp(-i*(q+G)*r)|wfr1>, where q 
> equals k-k1 and does not necessary lie within Brillouin zone. This q 
> may differ from (lying wihin the BZ) q used in qbz array -- by vector 
> G0.
> Also, we need to calculate Sum |<wfr|exp(-i*(q+G)*r)|wfr1>/|q+G||**2, 
> here sum is over G. If k-k1 lies outside BZ, does this module calculate 
> the quantity that we need?

It's exactly the role that igfftg0 plays which take into account k-k1 
beyond the 1st BZ by
a vector G0. tha G0 is found in the section of the code
!  else identify q and G0 where k1=k-q-G0
than it is used to form the table
igfftg0(:)
starting from the table igfft, AND the particular value of g0.
tha igfftg0 is passed to the routine rho_tw_g and when in the routine
at last there is the reorder of the coefficients in g-space, the G0 is 
taken into account.
up to a k-k1 in the 3rd BZ (it's largely enough).

> The second question deals with k-k1=q=0. In this case, matrix element 
> for G=0 diverges like q**-2. I see that teatment of (k=k1, n=n1, G=0) 
> matrix element is implemented for simple cubic lattice only. I see, you 
> refer to Baldereschi's article, but the code doesn't seem to be 
> according with it. Recently we tried to develop corrections in 
> according with Baldereschi's article.

Yes you are right. the constant 7.44 is for the fcc cell. for other 
cells you should
take into account the different shape giving different results when 
integrated.
Please consider that the important factor given by the volume cell is 
taken into account in that term, so changing symmetry you are wrong only 
in that "shape prefactor".
However that term becomes weightless as long as you increase the number 
of k-points
in the mesh. It's a term given only to accelerate convergence. We 
verified an error
of up to 50 meV (beyond the precision of a GW calculation) if you don't 
change
that prefactor with the symmetry.

To solve the problem you can calculate the prefactor by yourself
and change the code, recompile everytime you change symmetry,
or otherwise become a developper and give the correction to
this bug. There is something in the code (read in the header of the KSS 
file)
a variable giving the space group. In the point of the code where the 
constant 7.44
is used the program should be changed according to the space group.
This is something in our (gianmarco and me) agenda, but I cannot say when
will be possible for us.

Thank you very much

Valerio Olevano