Transferred momenta and different LongDrXd orientation

Deals with issues related to computation of optical spectra in reciprocal space: RPA, TDDFT, local field effects.

Moderators: Davide Sangalli, andrea.ferretti, myrta gruning, andrea marini, Daniele Varsano, Conor Hogan

zmar
Posts: 10
Joined: Mon May 09, 2022 2:48 pm

Re: Transferred momenta and different LongDrXd orientation

Post by zmar » Thu Mar 09, 2023 1:06 pm

Dear Davide,

we are sorry for the late reply but I was sick and then some family matters complicated my situation.

1) 'slab z':
We tested 'slab z' option without your patch (and with patch, initially) and it fixes the negative values problem.
Patch, no-patch, 'slab z' works fine; the patch does not affect the results both within and outside the 1st BZ.
Thank you very much for the hint.

The below plot displays the "bulk" ELF = Im{-1/eps} which confirms the many negative values of Im{eps} or Im{alpha} do not occur anymore.
Im1overEps_local_fields_kz_outOf1stBZ_zoom.pdf
2) Out of the 1st BZ:
We would like to calculate the 'alpha' and 'eps' for k-points outside of the 1st BZ along specific line-segments.
We would like to do this (more or less) equidistantly, already true within the 1st BZ.
Apart from line-segments containing Gamma, we would like to do this along the directions specified by M-L and K-H (in case of hexagonal cells).
Do you know of any easy way to set this up at the Yambo level?
Maybe, this is already implemented by an existing variable such as 'ShitedPaths'.

Our calculations within the 1st BZ along M-L and K-H show minimal variations (not displayed here) which is probably due to the z-component of the momentum being too small when compared to xy-components.
We expect that in sufficiently high order BZ, this may no longer be true.

Furthermore, the figure displaying ELF along Gamma-A direction exhibits a rather large gap in calculated distances from the Gamma-point.
There is a jump from 0.5 to 1.083 measured in iku units (see legend in the figure).
This means the calculated interval is not sampled equidistantly even though the initial k-points within the 1st BZ are equidistant.
Is there any symmetry to explain that this jump is only apparent (i.e. the segment Gamma-A is already equidistantly sampled)?

3) Information:
QDirection along the Gamma-A direction was not exactly preserved in some of our calculations along Gamma-A

Q(8) + G(17): 0.00000000 0.333333333E-1 8.00000000 [iku]

The 2nd coordinate deviates from expected zero values of both xy-components.
Is there any tolerance implemented?

Kind regards,

Martin
You do not have the required permissions to view the files attached to this post.
Martin Zouhar
(Institute of Scientific Instruments of the CAS, v. v. i.)

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

Re: Transferred momenta and different LongDrXd orientation

Post by Davide Sangalli » Thu Mar 09, 2023 4:08 pm

1) Nice that it works

2) From what I understand you need chi(q,w), with q moving along specific lines. If you have these lines as part of the q=k-k' grid you just need to select the proper points, right.
Instead if you mean that you would like to compute chi(q,w) at arbitrary q /= k-k this is not implemented.
It would require some work.

"ShiftedPaths" is what is implemented for computing the dipoles via d_{cvk}=<psi_{ck+q} | psi_{vk}>.
Here |psi_k> and |psi_k+q> are two different SAVE folders, containing two independent nscf calculations done with qe and q tipically ~ 10-5
It is not useful here. Well, maybe the handling of multiple SAVE folders could be the starting point for implementing chi(q,w) at arbitrary q.

3) What is reported as

Code: Select all

Q(8) + G(17): 0.00000000 0.333333333E-1 8.00000000 [iku]
is really the sum of the two momenta Q(8) and G(17)

The subroutine which selects the G is src/pol_function/OPTICS_select_q_and_G.F
I did not code it. I see there is a tolerance of 10^-5.
I'm a bit surprised it uses the v_norm function. I think it should use iku_v_norm, but maybe it is ok like that.

Best,
D.
Davide Sangalli, PhD
CNR-ISM, Division of Ultrafast Processes in Materials (FLASHit) and MaX Centre
https://sites.google.com/view/davidesangalli
http://www.max-centre.eu/

Post Reply