LRC

[Daniele Varsano]

Try to reduce further the parameters in order to have an idea of the needed memory.
Reduce the FFTGvecs parameter, this should help, set it lower than the cutoff on the wfs.
Actually I should look to this variable: EMStpsXd I do not remember now the meaning, I will do as soon as I have time.
In general, note that you are handling a grid of 976 k points which is rather big, are you sure that this is needed?

If none of this will help I would need to reproduce your error, but today I will be travelling back to Europe and I will be busy in the next days.
Daniele

[haseebphysics1]

Dear Daniele,

Reduce the FFTGvecs parameter

.

This has been proved to be the reason for memory overflow! I always forget to add this in input, and this time I even not realized after getting errors constantly!

By the way, I used ecutwfc = 100 Ry (via convergence testing) in DFT and I am going with FFTGvecs = 20 Ry to remain in the manageable limit of resources! Hoping it will be a converging number of G-vectors in the sum for my system!

Many thanks,

[Daniele Varsano]

Dear Haseeb,
20y over 100Ry is a quite dramatic reduction and should be checked a bit.
Anyway, I did notice this:

It is interesting that static LRC TDDFT is working with 118 GB RAM!

This sounds strange and adding the dynamical part should not require more memory: I will investigate on this issue in the next days when I find the time.

Best,
Daniele

[haseebphysics1]

Dear Daniele,

It is interesting that static LRC TDDFT is working with 118 GB RAM!

Kindly see the screenshot.

I think a large number of k-points might be the reason for a huge amount of memory, for 36 atoms big cell, I used 18 x 6 x 18 k-mesh (# of k-points were converged using convergence tests using RPA spectra of Q.E. epsilon.x).

I will investigate on this issue in the next days when I find the time.

Thanks, if you need input files, then I will send you.

Regards,

[haseebphysics1]

Dear Daniele,

I had computed the dipoles at the very start using yambo -o c and later did a lot of things like IPA + LFE corrections and even TDDFT (LRC) using the same computed dipole database -J directory (in the same directory). So, is it okay to use the same dipole database for later different calculations?


Thanks,

[Daniele Varsano]

Sure it is okay, provided that in the database you have the transition dipoles for all the bands you need in the following calculations. In case you need more dipoles that are not present in the database, yambo will complain and recalculate the database for all the needed transitions.
Best,
Daniele

[haseebphysics1]

Dear all, hopefully, everyone will be fine and doing well,

I want to know that in the following tutorial:

http://www.yambo-code.org/wiki/index.ph ... ed_kernel)

A negative value of alpha was chosen:

LRC_alpha= -1.200000 # [TDDFT] LRC alpha factor

So, what is the physical significance of negative alpha? Should not be it always positive? I know this is a material-dependent parameter but why the negative value was selected?

Thanks,

[Daniele Varsano]

Dear Haseeb,
I think this is just a convention on how the kernel is defined e.g. (alfa/q^2) or (-alfa/q^2).
In both case what it is important is that the interaction has to be attractive.
You can have a look to the phD thesis of Dr. Sottile, here the correct link.
see e.g. section 7.3.3

Best,
Daniele

[haseebphysics1]

Dear Daniele,

Thanks for sharing the useful resource.

Now, in Yambo, how the LRC kernel is defined? Since f_xc should be negative so I guess, f_xc= (alfa/q^2) will be the definition in Yambo, if we are providing negative alpha! Am I right or missing the interpretation?




Thanking and wishing you best health,

[Daniele Varsano]

Dear Haseeb,

Am I right or missing the interpretation?

Right!

Best,
Daniele