NaN/0-values in ANADDB for successful datasets

Running Abinit Response calculations
1

Hello reader,

I recently stumbled upon an issue that I have tried to tackle for over 2 weeks now but I don’t see the issue.
I’m running three datasets which I have performed using the legacy ephon workflow:

delta_delta_ephon.abi (8.7 KB)

After completing one of the three, I used anaddb using:

NbSe2H2_xi_xi_anaddb.in (18.4 KB)
This gave me a results with nonzero linewdiths. However, I noticed that many values were negative, corresponding to imaginary phonon modes at gamma and M, this was weird since during the DEN calculation, the phonon wavevectors all returned real values.
I made a small change: I set nstep to 0 for the wavefunction on the full BZ (note that I used the DEN file and WF file from the first datasets, so no SCF cycle is needed), and also for the calculation of the GKK elements. This returned real wavevectors across the BZ (except gamma, but that’s another issue, see my first post).

However, after running the same ANADDB.in file, I suddenly get 0-values for my linewidths. First I thought this was because of changing nstep but now I’m unsure since one of the other 2 datasets was performed in the exact same way and did not return zero-linewdith values:

anaddb_ep_A2F_QGRID.txt (43.0 KB)
Then I found that the calculations abruptly stopped with error (during GKK calculation), which I don’t know the meaning of:

--- !ERROR
src_file: m_dynmat.F90
src_line: 5809
mpi_rank: 0
message: |
zhpev returned: 23
...

But after completing all GKK files for all atoms in all directions. So this could also be the issue.

anaddb_delta_theta_A2F_QGRID.txt (43.0 KB)

delta_theta_anaddb.out.tgz (2.9 MB)
But then for the last of the three datasets, ANADDB also returns NaN linewidth values, but not with this error present. So now I’m very confused.

anaddb_delta_delta_A2F_QGRID.txt (43.0 KB)

The DDB and GKK merge were all successful as well. Anyone know a possible issue/solution to this?

regards, William

2

Hello,

First, the error you’re seeing means that the code cannot diagonalize the dynamical matrix, probably because it is singular. This means that there must be something very wrong in the response function calculation that produced the DDB files. I cannot tell what it is, because your input file does not specify the unit cell. Are there enough bands for your calculation? You should try plotting the phonon band structure with anaddb and see if it makes sense.

Then, I strongly suggest that you use the modern EPH approach to compute the lifetimes and linewidth through eph_task=-4, instead of the legacy ephon workflow. Have a look at the EPH tutorial.

3

Hello William,

First off, note you are using the legacy code, which is not developed or maintained at all. I feel morally responsible for it, but I think the only reason to use it is edge cases which are not possible with the new workflow, such as PAW or DFT+U. For TaS2 I don’t think you need either of those…

Second off, note Bogdan’s answer to your other posts, which is very important for the physics of CDW and their treatment with DF(P)T in general.

The freq grid goes slightly negative because it smears the DOS/a2F peaks with Gaussians, and expands to include a certain number of sigmas, including the acoustic modes at 0. This is delicate as you should be dividing by frequency sometimes, and you are counting on the gkk^2 going to 0 properly as they should. If you have soft modes which are too low in omega, it can be really problematic, but this is physics: the formulae presume (thermo)dynamic stability and no phase transitions.

The legacy code does a Fourier transform interpolation of the gkk^2 matrices, which is not guaranteed to be strictly positive definite. If your grid is fine enough, it should be ok, but otherwise you can get oscillations of the gkk^2 and the a2F can go negative, which is unphysical.

The fact that the merges succeed does not mean that the file contents are physical. You can interpolate the phonon band structure, either with bare anaddb or with the elphon part, and see if those go imaginary. The call paths are slightly different, and there can be small differences in frequencies. The elphon code is made for metals, so if the electron DOS is too small it can be hard to use (basically you need tons of k and q points, for physical reasons)

The frequencies along the path look ok and not imaginary (in the single out file you provide), but the lambda and line width are 0. The first set of points do not use interpolation, so if it gives 0, your GKK files contain 0s. You might try the NSCF calculations with nstep > 0, the convergence of your nscf dtset, or inspect the GKK files themselves (there is an option to print an ascii version).

Note the frequencies are slightly different (and break ASR ever so slightly) in the “Phonon energies in Hartree“ segment…

4

Hi,

Thank you for the reply Antonius and mverstra, I indeed forgot to include the unit cell. This is a more complete version:

delta_delta_ephon.abi (8.7 KB)
(the other one is similar)
I indeed had a look at the new EPH code but the issue that was holding me back at the time was that it was mentioned that spin-orbit was not supported yet, spin-orbit was a particular aspect that I wanted to study further.
But your points are very valid so I will try a calculation using the new routine to see what I get.

I did find a solution to the zero linewidths,

  • I set nstep back to 1 for the other datasets and now I get nonzero linewidths again, so there must’ve been a submitting issue on my side.
  • For xi_xi, nstep was set to 0 in the input file but during the run, and in the log it was set back to 1. This was the dataset which gave nonzero linewidths so not sure what happened there, hence the confusion from my first post.
    The error of the dynamical matrix being singular is also gone now.
  • One of the files (delta delta) is still ‘NaN’ but this is because the electronic DOS is near zero so that’s okay.
  • The electron DOS is very small, which as you mentioned is probably the reason why it is rather hard to use.

Thank you for the explanation, this helped a lot and will now do some more tuning with the grids, and the new EPH approach.

Regards, William