## TDDFT FFT call and RPA or IP questions

Deals with issues related to computation of optical spectra in reciprocal space: RPA, TDDFT, local field effects.
hongtang2023
Posts: 47
Joined: Thu Mar 16, 2023 7:02 am

### TDDFT FFT call and RPA or IP questions

Dear Yambo team,

I have basic some questions about TDDFT.

1. I copied a portion of the " subroutine TDDFT_ALDA_G_space(E,k) " of Yambo.5.1.1 , see below:

Code: Select all

``````call XC_potential_driver(E,k,WF_kind,WF_xc_functional,2)
do i1=1,fft_size
F_xc_DP(i1)=sum(cmplx(F_xc(i1,:,:),kind=DP))
enddo
!
! need to reset the plan to do a BACKWARD FFT (R->G)
!
fftw_plan=0
#if defined _FFTW
call fft_3d(F_xc_DP,fft_dim,-1,fftw_plan)
#else
call fft_3d(F_xc_DP,fft_dim,-1)
#endif
!
! F_xc in gspace
!
YAMBO_ALLOC(F_xc_gspace,(FXC_n_g_corr,FXC_n_g_corr,1))
do i1=1,FXC_n_g_corr
do i2=1,FXC_n_g_corr
F_xc_gspace(i1,i2,1)=cmplx(F_xc_DP( fft_g_table( G_m_G(i1,i2),1) ),kind=SP)/real(fft_size,SP)
enddo
enddo
``````
as I understand, "F_xc_DP " is the kernel, in which, at first, density n(r_i) is on the real space point r_i, n(r_i) has a size of "fft_size", then after " call fft_3d " , "F_xc_DP " becomes living in G space on each G point. However, the G grid has a size of " FXC_n_g_corr ". I found that in a tddft alda run, " FXC_n_g_corr " is not equal to "fft_size". "fft_size" represents the size of points in real space, while " FXC_n_g_corr " represents the size of points in G space, and they are mutually reciprocal Fourier spaces, so, why are the numbers of points in the two spaces not the same? According to FFT theory, they should be the same, right?

or, the " call fft_3d " did the "fft_size" of "F_xc_DP " on G space points, but only " FXC_n_g_corr " number of "F_xc_DP " on G space points is really used eventually?

2. For a TDDFT ALDA run, the EELS output file is "o-alda_q100.eel_q1_inv_alda_dyson", in which the 2nd column is ALDA EELS, what dose the 4th column "EEL_o-Im[4] " mean? is it the TDDFT run with the kernel=0 or so-called TDDFT-Hartree? or, is it the IP (independent particle level calculation, means no Dyson equation for the response function Chi )? Which is for the 4th column?

3. then, I did the same system with TDDFT ALDA, LRC and BSFXC (Chimod= "BSFXC"), from the 3 output EELS data, it shows that the 4th column from ALDA and LRC is almost the same, while the 4th column of BSFXC is very different from the previous two. If the 4th column is IP (independent particle level calculation), then the data from the three kernels should be the same, right?
Does GrFnTpXd= "R" or "T" matter for the 4th column?
I did not set GrFnTpXd for each run, but why GrFnTpXd will goes to different setting automatically?

In a different run (with Drude term), even I set GrFnTpXd= "T" or "r", but it will automatically become GrFnTpXd= "R", why is that?

Best,
Hong
Dr. Hong Tang
Tulane University
New Orleans, LA
70118, USA

Davide Sangalli
Posts: 620
Joined: Tue May 29, 2012 4:49 pm
Location: Via Salaria Km 29.3, CP 10, 00016, Monterotondo Stazione, Italy
Contact:

### Re: TDDFT FFT call and RPA or IP questions

Dear Hong Tang,

1. The big advantage of codes based on pseudo potentials is that the wave-functions in real space are smooth. This means that psi(r) on a real space grid of size "fft_size" can be represented in G-space into another grid of much smaller size, say "wf_ng", corresponding to an energy cut-off wf_ecut. This holds also for the density, but with a bigger grid, up to "rho_ng", corresponding to rho_Ecut=4*wf_ecut. The factor 4 is related to the fact that the density is a product of WFs in real space, and thus a convolution of WFs in G-space. In any case wf_ng<rho_ng<<fft_size. For the Fxc kernel I'm not sure how many G one would need in principle, I'd say that, since Fxc(G-G')*Delta rho(G')=Delta Vxc(G) one needs both G and G' to run up to rho_ng, and thus Fxc_ecut=4rho_ecut.

Anyway, that would be a huge number of G-vectors, and one solves the G-space tddft equations with a lower cut-off imposing that both G and G' runs up to FXC_n_g_corr. Also the code is limited to max FXC_n_g_corr=wf_ng, which would imply G-G' running up to rho_ng, and Fxc_ecut=rho_ecut. This is what happens in the subroutine you reported. First the FFT is performed, and then only the components up to the chosen cut-off are considered. Notice the "G_m_G" table which does the G-G'

2. 2nd and 3rd column are "TDDFT", 4th and 5th are "TDIP"

3. Chimode="BSFXC" should five exactly the same as TDHartree, e.g. Chimode="HARTREE" since the xc kernel is not coded at the moment. The input variable should be removed.
GrFnTpXd="R" or "T" is for the "ordering" of the Green function, e.g. if "T-ordered" or "retarded". It just affects some details of the response function, e.g. real/imaginary part of chi symmetric / anti-symmetric w.r.t w --> -w
"R" is automatically switched on for finite temperature calculations, e.g. occupations with smearing, since the T-ordered is correct only at zero temperature.
Davide Sangalli, PhD
CNR-ISM, Division of Ultrafast Processes in Materials (FLASHit) and MaX Centre
http://www.max-centre.eu/

hongtang2023
Posts: 47
Joined: Thu Mar 16, 2023 7:02 am

### Re: TDDFT FFT call and RPA or IP questions

Dear Davide,

Thanks so much for helping!

3. So, even "BSFXC" is TDHartree right now in Yambo5.1.1, the 4th column from TDHartree is different from TDDFT ALDA and LRC. It seems that the different is induced by GrFnTpXd="R" or "T".

for my case, TDDFT ALDA and LRC GrFnTpXd= "T", where ElecTemp= 0.861734E-5 eV and BoseTemp= 0.861734E-5 eV .

for "BSFXC" or really TDHartree in Yambo5.1.1, GrFnTpXd= "R", where ElecTemp= 0.344694E-4 eV and BoseTemp has no information in the output file.

So, 0.861734E-5 and 0.344694E-4 is enough to set finite or zero temperature?

Please let me know where I can find the detailed explanations for all the input keywords in Yambo code. The Yambo website seems has very limited information on those keywords. I want to see all detailed keywords explanations. Otherwise, how can we know how to use those keywords and use what keywords?

Best,
Hong
Dr. Hong Tang
Tulane University
New Orleans, LA
70118, USA

hongtang2023
Posts: 47
Joined: Thu Mar 16, 2023 7:02 am

### Re: TDDFT FFT call and RPA or IP questions

in my previous question:
"
In a different run (with Drude term), even I set GrFnTpXd= "T" or "r", but it will automatically become GrFnTpXd= "R", why is that? "

which should be

"
In a different run (with Drude term), even I set GrFnTpXd= "T" or "r", but it will automatically become GrFnTpXd= "R", but, for the same system, if without Drude term, then it is automatically GrFnTpXd= "T", why is that?
"

Dr. Hong Tang
Tulane University
New Orleans, LA
70118, USA

Davide Sangalli
Posts: 620
Joined: Tue May 29, 2012 4:49 pm
Location: Via Salaria Km 29.3, CP 10, 00016, Monterotondo Stazione, Italy
Contact:

### Re: TDDFT FFT call and RPA or IP questions

So, 0.861734E-5 and 0.344694E-4 is enough to set finite or zero temperature?
It might be.
Please let me know where I can find the detailed explanations for all the input keywords in Yambo code.
Have a look here: https://www.yambo-code.eu/wiki/index.ph ... heatsheets
In a different run (with Drude term), even I set GrFnTpXd= "T" or "r", but it will automatically become GrFnTpXd= "R", but, for the same system, if without Drude term, then it is automatically GrFnTpXd= "T", why is that?
It should be related to the electronic temperature. "T" at zero temperature, "R" at finite temperature
Davide Sangalli, PhD
CNR-ISM, Division of Ultrafast Processes in Materials (FLASHit) and MaX Centre
http://www.max-centre.eu/

hongtang2023
Posts: 47
Joined: Thu Mar 16, 2023 7:02 am

### Re: TDDFT FFT call and RPA or IP questions

Dear Davide,

Thank you so much for helping!

1. It is still very strange that ElecTemp= 0.861734E-5 eV is deemed as zero temperature and GrFnTpXd= "T" is set by the code, while ElecTemp= 0.344694E-4 eV is deemed as finite temperature and GrFnTpXd= "R" is set by the code. Since 0.861734E-5 and 0.344694E-4 are both very small and very close to each other, right?

For this calculated system, I did not set any "occupations", "smearing", and " degauss" in the quantum espresso run for the DFT calculations.

I am not sure how to use the tag "ElecTemp ". In a TDDFT calculation, Can I just set it as " ElecTemp = 0.024 eV " to say the room temperature? or just set is as " ElecTemp = 0.000 eV " to say the zero temperature ?

2. I know the cheatsheet. But Ican not find the explanations about " ElecTemp " or " GrFnTpXd " in the cheatsheet. I tried yambo -h ElecTemp and yambo -help GrFnTpXd, but it shows

unrecognized option 'GrFnTpXd' 'ElecTemp '

I also check https://www.yambo-code.eu/wiki/index.php/Variables for 'ElecTemp ' , it says
" ElecTemp (Units: Energy, Format: Real)Default: 0.000 Verbosity: -V gen
Meaning: Electronic Temperature
Usage: "
it says the default is 0.000, but in my runs I set it default, but I got 0.861734E-5 or 0.344694E-4 .

Best,
Hong
Dr. Hong Tang
Tulane University
New Orleans, LA
70118, USA

Davide Sangalli
Posts: 620
Joined: Tue May 29, 2012 4:49 pm
Location: Via Salaria Km 29.3, CP 10, 00016, Monterotondo Stazione, Italy
Contact:

### Re: TDDFT FFT call and RPA or IP questions

1. It is still very strange that ElecTemp= 0.861734E-5 eV is deemed as zero temperature and GrFnTpXd= "T" is set by the code, while ElecTemp= 0.344694E-4 eV is deemed as finite temperature and GrFnTpXd= "R" is set by the code. Since 0.861734E-5 and 0.344694E-4 are both very small and very close to each other, right?
If your system is a metal, with a finite grid, it might well be that:
- 0.86E-5 gives 0 or 1 for all occupation factors
- 0.34E-4 gives some fractional occupation factor
The result would probably depend on the k-mesh
I am not sure how to use the tag "ElecTemp ". In a TDDFT calculation, Can I just set it as " ElecTemp = 0.024 eV " to say the room temperature? or just set is as " ElecTemp = 0.000 eV " to say the zero temperature ?
You can set whatever you want. It defines the occupation factors.
Then the physical interpretation depends on what you aim to describe, it can be a finite temperature effect or it can be used to speed up the convergence against the k-points mesh

Best,
D.
Davide Sangalli, PhD
CNR-ISM, Division of Ultrafast Processes in Materials (FLASHit) and MaX Centre