DIPOLE_driver strategies

[andreamarini]

In maintenance-dipoles I am refactoring the DIPOLES evaluation.

I need some help to understand the current strategy.

In DIPOLE_driver.F I read

 ! DIP_iR=i<r>
 ! DIP_P = <P>
 ! DIP_v = <v> = <P-[x,Vnl]>
 !
 ! For each of the two gauges there exist four approaches of computing the dipoles
 ! 1) G space approach      --> directly computes <v> and then <r>=<v>/DeltaE (called transverse approach as well)
 ! 2) real space approach   --> directly computes <r> and then <v>=<r>*DeltaE (only for non periodic directions)
 ! 3) shifted kpts approach --> computes q*<nk|r|mk> as <nk|r|mk+q> with small q (phases not defined)
 !                              and then <v> as <r>*DeltaE
 ! 4) covariant approach    --> computes <nk|r|mk> in reciprocal space as <nk|partial_k|mk>
 !                              takes into account the phases. symmetries not yet implemented 
 !                              and then <v> as <r>*DeltaE
 !

However later in the source I read

 Dip%force_v_g_space     =Dip%force_v_g_space.or.l_BS_photolum
 Dip%force_v_g_space     =Dip%force_v_g_space.and.(.not.use_g_space_approach)
 **use_dipole_transverse   =.true.**
 idir_not_done           =.true.

This the G space routine is always called. Why?

In addition there are no warnings on the real space/covariant approaches. An non expert user would find really difficult to avoid errors.

[sangallidavide]

• use_dipole_transverse is set to .true. because yambo always enters in the subroutine DIPOLE_transverse to compute at least <p>, which cannot be obtained in any other way. Indeed, in the initial description, it is explained only how <x> and <v> are computed using one of the 4 approaches. It could be added before: <p> is always computed in G-space

• force_v_g_space is set to .false. in case the g-space approach is used, because there is nothing to force in such case.

• force_v_g_space is set to .true. for PL... to me there is no reason for that, and that line should be removed

• idir_not_done is set to .true., because in DIPOLE_driver, DIPOLE_x_real_space needs to be called with 3 .true. as last argument

• Why should a user get a warning of the real-space/covariant dipoles?
  They are not the default, and they are well documented in the yambo paper.

[andreamarini]

If there are tutorials explaining the pro/cons and computational difficulties then no prob with me.

My opinion is that the Yambo paper is not enough but we need code-specific documentation. So anything without a tutorial that explains carefully how to use the code should not be officially released.