fsthick in graphite

[aurelien]

Hi, I have seen the v5.3 has been released.
I need some help with the variable fsthick.

I have set this variable fsthick=1 for the wannierization step and writing down the epb files, which would correspond to the first step that Mehmet (previous post) or the school example did (available online at indico.ictp.it).
For step 2, when I want to plot the phonon dispersion of the interpolated bands, no matter what value I include in fsthick I always obtain a q-list of 0 from the 238 initially found.

My first question is: Shall I restart the step 1 calculation commenting out fsthick to have all k/q list written correctly?

In the nscf calcualions, I have 16 bands and I choose nbdsub=10 to have only 8 wannier function + 2 more in the valence band.
In principles, I expect contributions coming from the 2 valence bands being near to the Fermi level, so I expected 1 eV to be fine.

However, I have seen from previous EPW versions that I always needed to set this value up to 3-4 eV to have a continuous dispersion plot.
If we do not have a continuous dispersion plot, we might raise additional problems when calculating the electron-phonon self energy, is this right?
Finally, do you think if I need to set fsthick larger it could be explained due to a wrong choice of wannierization and projections? I am using very close settings than example 10 (graphite as well) of the wannier90 folder.

Kind Regards,
Aurelien

[hlee]

Dear Aurelien:

For step 2, when I want to plot the phonon dispersion of the interpolated bands, no matter what value I include in fsthick I always obtain a q-list of 0 from the 238 initially found.

My first question is: Shall I restart the step 1 calculation commenting out fsthick to have all k/q list written correctly?

First, I would like to look at your epw.in and epw.out.

Regarding your first question: fsthick doesn't affect the first step of EPW, that is, you can restart calculations using epb files with epbread=.true. or epmatwp file with epwread=.true.

In the nscf calcualions, I have 16 bands and I choose nbdsub=10 to have only 8 wannier function + 2 more in the valence band.
In principles, I expect contributions coming from the 2 valence bands being near to the Fermi level, so I expected 1 eV to be fine.

fsthick is not responsible for the band manifold for the Wannierization step which is controlled by the Wannier90 input flags (dis_win_min, dis_min_max, dis_froz_min, and dis_froz_max) and the number of bands in nscf calculation.
fsthick just controls the band range or k (q)-point range in the 2nd step of EPW in which quantities on the fine Bloch k (q) grids are calculated.

If we do not have a continuous dispersion plot, we might raise additional problems when calculating the electron-phonon self energy, is this right?

Yes. If some k or q points are filtered out by the specific value of fsthick, they are not considered in calculation of the e-ph self energy.

Finally, do you think if I need to set fsthick larger it could be explained due to a wrong choice of wannierization and projections? I am using very close settings than example 10 (graphite as well) of the wannier90 folder.

As I said above, fsthick is not related to the Wannierization step. For example, even if your Wannierization step is perfect, you can get the discontinuous phonon dispersion on fine q grids if your fsthick is very small so that some q points are not filtered out.

Sincerely,

H. Lee

[aurelien]

Dear H. Lee,

Thank you for the reply and for clarrifying what role does play fsthick in the calcualtions.

Please find attached the epw.in/out files as well as epw2.in/out I used to plot the interpolated bands.
As discussed previously, the number of q-points drop to 0 in the second step. Hence, I cannot have a phonon dispersion plot.
However the electronic band structure looks correct.

Kind Regards,
Aurelien

[hlee]

Dear Aurelien:

Thank you for providing your inputs and outputs.

Recently, when I implemented some functionality in EPW, I found one suspicious thing in the subroutine of qwindow which takes care of filtering q points.

In order to confirm that this is related to your issue, I would like to kindly ask you the following four things:
(1) Could you show me the phonon dispersion along the same q path as that in graphite_band.kpt obtained by using matdyn.x of the Quantum ESPRESSO suite?
(2) Could you show me the electronic band structure along the k path in graphite_band.kpt obtained by using epw.x?
(3) Did you try to run a calculation with the line of fsthick removed or commented out? That is, no filtering of q points.
(4) Could you show me your graphite_band.kpt?

Sincerley,

H. Lee

[aurelien]

Dear H. Lee,

I have run again the calculations to make sure I haven't missed anything preparing the inputs for epw.

First, I run scf phonons q2r and matdyn in a separate folder.
Then, I use the python script pp.py to save the .dyn files for epw.
In the epw folder, I run scf nscf and epw.

(3) Did you try to run a calculation with the line of fsthick removed or commented out? That is, no filtering of q points.

Yes, I have commented out fsthick in epw2.in but I still face same output of 0 q-points selected.
I have also written crystal or cartesian close to 238 under graphite_band.kpt because it now complains since you have choice between those 2 options on newest version.

(1) Could you show me the phonon dispersion along the same q path as that in graphite_band.kpt obtained by using matdyn.x of the Quantum ESPRESSO suite?
(2) Could you show me the electronic band structure along the k path in graphite_band.kpt obtained by using epw.x?
(4) Could you show me your graphite_band.kpt?

You can find all the answers inside the attached file.

Regards,
Aurelien

[aurelien]

Dear H. Lee,

I also 'd like to add than in previous epw versions I got a good calculation of the phonon dispersion.
At the time I used 20 bands in the nscf and epw scripts.

Please see the attached figure.

Regards,
Aurelien

[hlee]

Dear Aurelien:

First, your issue is not related to the suspicious thing I mentioned in my previous post.
Second, although it is obvious that something strange is happening in your calculations, unfortunately I can't give you the clear solution. The best way is to reproduce your calculations using all your data, but it is not easy.

I think that you have to dig into the code to see what happens in your calculations.

Before doing this, I would suggest you the followings:
(1) It seems that you obtained the band structures from the call to Wannier90 library in EPW calculations.
You have to confirm that you obtained the same band structures from the band_plot mode of EPW calculations. For this purpose, you have to check the file of band.eig .

(2) You have to look at the file of selecq.fmt, in particular, the first and the second lines.

(3) You used use_ws=.true. in the first step of EPW calculation, but you used use_ws=.false. in the second step. It is not good since you restarted with prefix.epmatwp file. So you have to use use_ws=.true. in your restarts with prefix.epmatwp.

(4) Consequently, you have to rerun the second step of EPW calculation with use_ws=.true. and in order to make situations simple, you had better use only one core (previously you were using 256 cores). This band_plot mode takes little time.

If you still encounter the same issue, you have to dig into the code by printing out the relevant variables and arrays such as etf_tmp, ef, fsthick, and found. In your case, very strangely all values of found are zero, leading to 0 q points after the call to qwindow.
You just need to focus on the relevant part (line 1529 to line 1654) of the subroutine of qwindow in EPW/src/grid.f90 .
(I assume that you are using the official release of EPW v5.3 contained in QE v6.6 which can be downloaded at https://gitlab.com/QEF/q-e/-/releases .)

Sincerely,

H. Lee

[aurelien]

Dear H. Lee,

I have done all the suggestions you brought.
Thanks, it seems to select 238 qpoints and rewrite select.fmt correctly 238 for the two first lines.
So let see when it finishes if the band structure found is coherent.

I guess I got stuck for inconsistency values between epw.in and epw2.in when reading epbmat files as you mentioned for example use_ws=.true., for some reasons I commented out this line in epw2.in.
I also run the code with one core.

Kind Regards,
Aurelien

[aurelien]

Dear H. Lee,

Everything works fine now that I have written use_ws=.true. and kept same consistency with the first epw calculations.
Thanks.

Kind Regards,
Aurelien