The ABINIT Users Mailing List ( CLOSED )

["Allan, Douglas C Dr" <AllanDC@corning.com>]

The indexing for rhog does not work the same as for rhor, and not just because it is complex instead of real.

 

Recall that there is some subtlety involved in using an FFT and keeping track of which part of the array on the computer holds what planewave coefficient.

The planewave coefficients of rho(G), or the FFT of rhor, can be thought of as a parallelipiped with edge lengths of G1, G2, and G3 (three nonplanar vectors in G-space or reciprocal space).

The tricky part is that, as you increase the array index and go away from G=0 (say along the G1 direction first), you actually pass out the face of this parallelipiped when the index is about N1/2 (for an FFT grid of size (N1, N2, N3)) and you come back in (in the periodic boundary condition sense) through the opposite face.

This means the G-value becomes negated at that next index value, and then you proceed moving along as you raise the index until you are one step short of the origin again.

Then you start over again displaced one step in the G2 direction.  And so forth.

It is as though you carve up the G-vectors in reciprocal space and move the octants around so that the origin (G=0) is at the center instead of in the corner.

To achieve this you have to take the largest G-vectors and map them back to negative values by using the periodicity.

That way G=0 becomes surrounded by other G-vectors instead of being isolated in a corner.

This is done because of the definition of the phase factor in the FFT -- it is a way of getting the FFT to calculate what we really wanted physically in terms of G-vectors.

In real space we leave the origin in the corner so this issue does not arise.

 

If this is not familiar to you then you need to look up FFT indexing and the effect of periodic boundary conditions in a text like Numerical Recipes or any other.

 

If you can't sort this out satisfactorily then ask again and I will try to spell it out element by element.

 

I just checked that there is a routine called "kgindex" that has brief comments and an algorithm that are relevant.

It tells you the linear array index corresponding with any triplet of G-vector indexes.

Another related routine is kpgsph, where in this case the "G-sphere" is centered not on G=0 but rather on a given k-point.

You can see in that subroutine how the mapping described above is used.

 

Regards,

Doug Allan

 

 

---

From: Adam Sorini [mailto:asorini@gmail.com]
Sent: Sunday, May 25, 2008 12:45 AM
To: forum@abinit.org
Subject: Re: [abinit-forum] rhog

On Sat, May 24, 2008 at 4:02 AM, Anglade Pierre-Matthieu <anglade@gmail.com> wrote:

Hi,

It is quite possible that :
1 ) someone  mistakes in a comment and possibly also in some part of the code
2 ) something else is called rhog ...
3) other ? Where did you found this comment ?

it was in abinit-5.2. I found it in abinit-5.2.4/src/11drive/outscfcv.F90 comments at begining of file.

thanks for the other pointers. they seem very helpful. cheers,

adam
 

However the definition I took for rhog is that used in the main
density evaluation routine : mkrho
(http://www.abinit.org/package/robodoc/15common/mkrho_F90.html#robo731)

About nfft : did you already find the documentation of this word
(http://www.abinit.org/Infos_v5.5/input_variables/varint.html#nfft) ?

Also there is some routines that computes the G vector associated with
each component. I can't remember their name but here is the one I
wrote, from them, that compute G^2
http://www.abinit.org/package/robodoc/13recipspace/laplacian_F90.html#robo_top_of_doc

regards

PMA

On Sat, May 24, 2008 at 2:25 AM, Adam Sorini <asorini@gmail.com> wrote:
> On Fri, May 23, 2008 at 4:51 PM, Adam Sorini <asorini@gmail.com> wrote:
>>
>> On Fri, May 23, 2008 at 1:15 AM, Anglade Pierre-Matthieu
>> <anglade@gmail.com> wrote:
>>>
>>> Hi,
>>>
>>> Rhog is defined as rhog(2,nfftf). Where nfftf is the number of grid
>>> point. rhog(1:i) is the real part of rhog at the ith gread point and
>>> rhog(2,j) the imaginary part of the same number ...
>>
>> ahha. okay, thanks very much for the information. This does seem to make
>> sense and compare well with my independently performed fourier transform of
>> rhor. I think my confusion comes from the comments in the code. In
>> particular, one reads:
>>
>> !! rhog(nfft,nspden)= total electron density in electron/bohr**3,
>> reciprocal space
>>
>> so I thought the implied meaning of the components was the same as for
>> rhor, a la section 6.5 of the abinit help file... but this is not the case?
>> For example, then there is no spin dependence in the fourier components of
>> rho?
>
> actually, after a bit more looking around I see that there is also a rhogsp
> variable which, I presume, may be used for spin dependent calculations.
>
> so, now my only confusion is about how exactly the ifft index on rhog works.
> Any help in this regard would be much appreciated.
>
> Cheers,
>
> adam
>
>>
>> Otherwise is the indexing of rhog analagous to that of rhor? I.e., if I
>> have reciprocal lattice vectors {Q_1, Q_2, Q_3}, then:
>> rhog(1,1) is the real part of the g=0 component; rhog(1,2) is the real
>> part of the g=Q_1 component; rhog(1,3) is the real part of the
>> g=2Q_1 component; and so on up to ifft=ngfft(1)? And the at
>> ifft=ngfft(1)+1 rhog(1,ifft) is the real part of the g=Q_2 component; and
>> the next index is the g=Q_1+Q_2 component, and next 2*Q_1+Q_2 components,
>> and so on similarly to the indexing of rhor?
>>
>> Thanks very much,
>>
>> Adam
>>
>>>
>>> About getting rhog without modifying the code... I don't know if this
>>> is possible however the modification would be quite light if nobody
>>> did it before. for instance,  you can just  find the routine that
>>> print rhor and provide it rhog instead ...
>>>
>>> regards
>>>
>>> PMA
>>>
>>> On Fri, May 23, 2008 at 9:44 AM,  <asorini@gmail.com> wrote:
>>> > Hi,
>>> >
>>> >  I've searched through the archive for a response to this question, but
>>> > I can't
>>> > seem to find one. I've found one person who asked the same question in
>>> > 2003,
>>> > but it seems to have never been answered.
>>> >
>>> > Anyways, my question is about rhog, the Fourier components of rhor.
>>> > I've been
>>> > able to print out rhog by adding a line of code to one of the outscf
>>> > subroutines. I've checked that the g=zero component (the component
>>> > corresponding to index=1) gives the average electronic number density,
>>> > but I'm
>>> > a little confused as to the other components. In a general system
>>> > (without
>>> > inversion point?) rhog should be complex, but in ABINIT rhog looks to
>>> > be a
>>> > real. How is this possible?
>>> >
>>> > Also, is there a way to get rhog output from ABINIT without modifying
>>> > the code?
>>> > As an option for prtden card? I didn't think so, but maybe it is a
>>> > secret.
>>> >
>>> > Also, I am confused about the indexing of rhog. Originally I would have
>>> > thought
>>> > that the indexing of rhog works the same as for rhor, but in reciprocal
>>> > space... but since the rhog variable is real and not complex in ABINIT
>>> > I'm not
>>> > sure if this is the case... Has anyone else looked into this or is
>>> > anyone able
>>> > to offer advice? thanks in advance.
>>> >
>>> > Adam
>>> >
>>>
>>>
>>>
>>> --
>>> Pierre-Matthieu Anglade
>>
>
>

--
Pierre-Matthieu Anglade