ABINIT Discussion Forums

Hi,

I'm finding an issue in 7.4.2 that I've never run into before--DDB's that fail to merge because they differ in the ngfft variable. I'm computing the phonon dispersion using PAW, and find that ngfft is set to different values for the different data sets. In this case, mrgddb complains and quits. I've never seen this before--is this a side effect of a new feature, or do I have something odd in my input that I wasn't aware of? (I've done lots of such calcs over the years, with NCPP, and never seen this before).

thanks,
Joe

Hi Joe

This is the consequence of our correcting a bug in the DFPT. The problem was that in the DFPT calculation, the qpoint coordinate was not taken into account in the calculation of the boxcut ratio, and it yielded boxcut ratios that were < 2.0 and large numerical discrepancies in the calculation (phonon frequencies went nuts). Marc has corrected this so that the DFPT takes into account the qpoint coordinate, but it sometimes changes the ngfft and mrgddb cries because of that.

What I do is that I change by hand the ngfft so that it matches in all DDB. It doesn't have any influence (I think) on the results.

Eventually we will probably modify mrgddb so that it tests the ngfft and keeps the highest values in the output file.

Hope this helps
Boris

PS : DFPT in PAW is still buggy. There is an issue with the koint distribution that prevents the acoustic sum rule to be satisfied even when rfasr = 1.

Thanks for the update. You mean you modify ngfft within the output DDB files? This will really confuse the users, wouldn't it be better to make mrgddb simply ignore this discrepancy?

Also, I am finding that PAW DFPT seems to be much more sensitive to the PAW sets than other PAW calculations (IMHO). For example, using PAW sets I have made that give good results on stishovite for many calculations, the phonon convergence is terrible, while the GBVR PAW (re-made with LDA) seem to be converging really well. I don't really understand this but thought I'd toss it out there.

Joe

Thanks for the update. You mean you modify ngfft within the output DDB files? This will really confuse the users, wouldn't it be better to make mrgddb simply ignore this discrepancy?

Also, I am finding that PAW DFPT seems to be much more sensitive to the PAW sets than other PAW calculations (IMHO). For example, using PAW sets I have made that give good results on stishovite for many calculations, the phonon convergence is terrible, while the GBVR PAW (re-made with LDA) seem to be converging really well. I don't really understand this but thought I'd toss it out there.

Joe

jzwanzig wrote:Thanks for the update. You mean you modify ngfft within the output DDB files? This will really confuse the users, wouldn't it be better to make mrgddb simply ignore this discrepancy?

Also, I am finding that PAW DFPT seems to be much more sensitive to the PAW sets than other PAW calculations (IMHO). For example, using PAW sets I have made that give good results on stishovite for many calculations, the phonon convergence is terrible, while the GBVR PAW (re-made with LDA) seem to be converging really well. I don't really understand this but thought I'd toss it out there.

Joe

Yes I modify ngfft in every DDB file output by abinit. But you are right, I think it would be simpler to have mrgddb simply ignores it, except if anaddb needs it afterwards. In case anaddb needs it, we need mrgddb to consider the highest value of ngfft.

DFPT is still a little buggy at the moment, but we are working on it and it's getting better. The main issues with 7.4.2 we are aware of are :
- the fact that usexcnhat = 1is usually mandatory for a good convergence of the DFPT calculation. From what you just wrote regarding your PAW datasets, you might want to try this option for a better convergence.

- also, the band parallelisation is not working right now, and it triggers automatically if the number of cpus is greater than nsppol*nkpt (reduced number of kpoints in the DFPT calculation). When band parallelisation activates, abinit still runs, but the convergence is terrible (and usually never exceeds 1.0E-02)

- the scheme for kpoint parallelisation sometimes (not to say always) yields an incorrect kpoint distribution when nsppol=2. This has two major issues: the first one is that if the total number of cpus is not a multiple of nsppol*nkpt (number of kpoints in the GS calculation), abinit freezes after printing the boxcut ratios. However, even if the number of cpus is a multiple of nkpt*nsppol, the number of kpoints is reduced afterwards in the DFPT part depending on the direction of the perturbation, and these kpoints are not correctly redistributed. The symptom for that is that abinit will give large negative frequencies and frequencies at Gamma won't be zero, even if you set rfasr=1 in abinit or in anaddb.