Hi All,
I have noticed that in the screening step the amount of memory needed increases with each k-vector when calculating chi0(q=(0,0,0), omega, G, G").
This happens for a while before the memory demand is reduced.
I do not know much about the structure of the code, but is it a good idea to store this info on file and re-read it when needed.
I would be happy to implement this if you think this is a good idea.
Best, Wissam
chi0/memory
Moderators: maryam.azizi, bruneval
Re: chi0/memory
Could you provide the input file of the calculation?
I bet you are using the default values for symchi and inclvkb (0 and 1 respectively)
Note that
1) inclvkb=2 is much faster and less memory demanding than inclvkb=1.
2) symchi=1 considerably reduces the CPU time as only
a restricted number of k-points have to be summed.
If I'm correct then there's no bug in (that part of) the code.
The arrays needed for the treatment of the optical limit
are indeed allocated and calculated inside the loop over the transitions.
I cannot free them since they are needed for performing the
integration over the full BZ. Their evaluation is CPU demanding thus I decided
to keep everything in memory.
Using symchi=1 avoids the storage of these arrays since each k-dependent table
is calculated only once and then released as soon as the k-point in the IBZ
has been summed.
M
I bet you are using the default values for symchi and inclvkb (0 and 1 respectively)
Note that
1) inclvkb=2 is much faster and less memory demanding than inclvkb=1.
2) symchi=1 considerably reduces the CPU time as only
a restricted number of k-points have to be summed.
If I'm correct then there's no bug in (that part of) the code.
The arrays needed for the treatment of the optical limit
are indeed allocated and calculated inside the loop over the transitions.
I cannot free them since they are needed for performing the
integration over the full BZ. Their evaluation is CPU demanding thus I decided
to keep everything in memory.
Using symchi=1 avoids the storage of these arrays since each k-dependent table
is calculated only once and then released as soon as the k-point in the IBZ
has been summed.
M
Re: chi0/memory
Dear Matteo,
I am facing problems with memory resources for a GW calculation, precisely at the convergence of the screening.
I have read your replies and suggestions at this regard on other posts, e.g.
http://forum.abinit.org/viewtopic.php?f=11&t=742&p=2194&hilit=inclvkb#p2194
and I wonder if any of the following would introduce a drastic, erroneous, approximation for a GW calculation on graphene at the special K-point,
1) inclvkb=0 # omitting commutator F(r1,r2) = [Vnl(r1,r2),r2]
2) symchi=1 # only a restricted number of k-points are summed.
I should mention that I am using a 30 x 30 x 1 kpoint grid in all the steps (ground state, KSS, SCR, and SIGMA), and ecut=35 Ha with TM pspnc pseudos.
I do get a zero LDA bandgap at K, but unfortunately the GW bandgap I get at K is 0.147 eV. The ABINIT version I am using is v6.6.2.
Best regards,
Temok
I am facing problems with memory resources for a GW calculation, precisely at the convergence of the screening.
I have read your replies and suggestions at this regard on other posts, e.g.
http://forum.abinit.org/viewtopic.php?f=11&t=742&p=2194&hilit=inclvkb#p2194
and I wonder if any of the following would introduce a drastic, erroneous, approximation for a GW calculation on graphene at the special K-point,
1) inclvkb=0 # omitting commutator F(r1,r2) = [Vnl(r1,r2),r2]
2) symchi=1 # only a restricted number of k-points are summed.
I should mention that I am using a 30 x 30 x 1 kpoint grid in all the steps (ground state, KSS, SCR, and SIGMA), and ecut=35 Ha with TM pspnc pseudos.
I do get a zero LDA bandgap at K, but unfortunately the GW bandgap I get at K is 0.147 eV. The ABINIT version I am using is v6.6.2.
Best regards,
Temok