Page 1 of 1
Coulomb cutoff & convergence
Posted: Wed Mar 04, 2015 2:01 pm
by asanchez
Hi all,
I'm working on 1D systems mostly (ie. nanowires) and am finding that the part of the calculation related to the coulomb cutoff box can take a long time. Are there any parameters one could converge with the coulomb cutoff turned off and just turn it back on afterwards? I have noticed for example that the value of EXXRLvcs influences how long the calculation of the coulomb cutoff box takes so I guess that's one parameter that shouldn't be converged independently? Would that be the case for every other parameter?
I'm mainly interested in self energy corrections in case that's relevant.
Thanks for your help
Re: Coulomb cutoff & convergence
Posted: Thu Mar 05, 2015 10:19 am
by Daniele Varsano
Dear Alfonso,
yes I would say that convergence studies should be independent on the shape of the coulomb potential.
EXXRLvcs is usually a big number so when using the coulomb cutoff you need to calculated the coulomb cutoff potential for many components.
Anyway consider that the coulomb cutoff need to be calculated just once for all, next once the database is produced it is read for all other calculations.
Best,
Daniele
Re: Coulomb cutoff & convergence
Posted: Thu Mar 05, 2015 10:45 am
by asanchez
Dear Daniele,
Thanks for your reply. I have found that the file db.cutoff (This is the only file related to the coulomb cutoff right?) changes when varying other parameters such as BndsRnXp, NGsBlkXp and GbndRnge (actually it seems to vary if you change the value of pretty much any parameter, or at least running a diff on the files reports them as different). Would it be OK then to just read the same db.cutoff all the time whilst studying convergence? Which one should I read? One converged wrt EXXRLvcs or it doesn't even matter if it's converged wrt anything?
Thanks again,
Alfonso
Re: Coulomb cutoff & convergence
Posted: Thu Mar 05, 2015 11:07 am
by Daniele Varsano
Dear Alfonso,
the db.cutoff contains the components V(G) of the cutoff coulomb potential. It is totally independent from the other variable you are mentioning.
You can calculate it once for all (yambo -c) and then use it for all the calculations.
The fact that the files of different runs can differ, it is only the serial number and the fact that the box is based on the RIM (Random integration method), I assume you are using something like"
Code: Select all
RandQpts=1000000 # (RIM) Number of random q-points in the BZ
RandGvec = 1 RL # (RIM) Coulomb interaction RS components
as integrals over the BZ are needed to build up the box coulomb potential, so you can have slightly different values as it is based on a Monte Carlo integration, but they are essentially the same.
What can change is the number of components, if you calculate for few of them, and then you ask for more Gvectors, but if you calculate at the beginning for all, or many components then you can use that database for all the rest of calculations.
Please note that once the database is created it is read and used in different steps, but not modified.
Best,
Daniele
Re: Coulomb cutoff & convergence
Posted: Thu Mar 05, 2015 11:25 am
by asanchez
That is quite interesting. I just have one more question:
Daniele Varsano wrote:
What can change is the number of components, if you calculate for few of them, and then you ask for more Gvectors, but if you calculate at the beginning for all, or many components then you can use that database for all the rest of calculations.
What do you mean by components? RandGvec? FFTvecs? EXXRLvcs?
Thanks again.
Best,
Alfonso
Re: Coulomb cutoff & convergence
Posted: Thu Mar 05, 2015 11:40 am
by Daniele Varsano
Dear Alfonso,
with components I mean reciprocal space G vectors.
If you calculate the cutoff database at the beginning (yambo -c) by default all the components are taken into account.
If you want, you can reduce them using the variable FFTGvecs.
Best,
Daniele
Re: Coulomb cutoff & convergence
Posted: Thu Mar 05, 2015 11:46 am
by asanchez
Thanks for your help Daniele. You've been very helpful (as always!)
All the best,
Alfonso