Better presets for DOS calculations

[dyllamt]

@ardunn and I had trouble getting reasonable DOS with the atomate KPOINTS defaults. Right now the default is reciprocal_density=100, but that only gives us ~35 kpoints for a unit cell with three atoms.

I attached a sample DOS that we get with a slightly higher reciprocal_density=400, but this is obviously too low also.

Also, hoes the atomatic kpoint generation scheme in pymatgen compare to the KPPRA spec used by AFLOW? It might be nice if we used the same spec.

[mkhorton]

Yes, for pymatgen the default needs to be increased to at least match atomate's. Also, I suspect the default ISMEAR in pymatgen is not optimal, since it should be -5 for semiconductors (ie using tetrahedral integration). Ideally this could be set in the from_prev method so that you can auto detect the gap. I haven't checked, but wherever the small gap multiply code is might also be a good place to put this.

A quick benchmark + recommended settings would be very welcome for this, because we want to improve the MP DOS also, and we would like to run a large batch of calculations soon, but no one is currently working on this (happy to correspond over email about this also).

[utf]

Just to say, tetrahedron integration is also good for metallic NSCF calculations. The two cases where ISMEAR = -5 should not be used are:

• Metallic relaxations as it gives bad forces.
• Line mode band structures, where it is incompatible with explicit k-points.

I updated the MPNonSCFSet in pymatgen a couple of months ago to use tetrahedron integration when possible. Is that not getting propagated to atomate?

[mkhorton]

Thanks @utf! That makes sense, my impression was that it was bad from a convergence POV (even electronic convergence, not just for forces), but if you're explicitly doing non-SCF / from a pre-converged SCF calculation, this will presumably not be an issue.

@dyllamt you may want to check the NEDOS value also, I think this is too low.

[shyuep]

@utf @mkhorton I think the fundamental problem here is that we do not know what is a metal (except for the well-known ones) until we have run a calculation. Does MP redo a relaxation with ISMEAR=1 when a zero gap is detected?

Also, if ISMEAR=1 is already used in relaxation, there is no reason not to propagate it to the NSCF calculations, unless there is a distinct benefit to tet method that I do not know about?

[shyuep]

Also, one idea is to basically use a ML classifier for gap vs non-gap prior to setting ISMEAR.... There are a number of such classifiers which are > 90% accurate and we can of course set the threshold to favor classification as nonmetal.

[utf]

@shyuep Agree that for optimizations the default should be to use gaussian/Fermi broadening to be safe.

For static/non-SCF calculations the two main benefits are:

• Much nicer density of states plots. See the phonon density of states on MP for an example.
• More accurate total energies (although this is benefit is probably lost by our choice of EDIFF and really only matters for magnetic ordering calculations).

[utf]

Oh, I've just realized the default ISMEAR for MP relaxations is already -5, and I probably misread @shyuep's messages.

I guess there are three options then:

• Use ISMEAR = -5 by default for optimizations, accepting small errors in the relaxations for metals.
• Use ML to predict metals in advance.
• Use ISMEAR = 0 by default for optimizations.

Is there a downside to the last option? Is it convergence issues?

[shyuep]

@utf I have been asking MP to change the simulation scheme for some time. In my view, the protocol should be: i. Relax with low(er) kpoints. The typical recp density of 100. ISMEAR=-5 if possible, otherwise ISMEAR=0. ii. Relax with denser kpoints and EDIFF=1e-4 (at least) and EDIFFG=-0.05. ISMEAR=1 if step i is zero gap. iii. If vol change > 10%, repeat. This is seriously missing. We need this to ensure that we have converged structures. iv. Static with Gamma k-points and ISMEAR=-5. ....all other simulations from this point.

[mkhorton]

Atomate does now have the half k-point relaxation option (courtesy of @shyamd), but I find it often leads to failed calculations, ie we need to determine how low “low” kpoint density should be for the initial relaxation.

Otherwise I agree with this.

On Mon, Mar 25, 2019 at 14:03, Shyue Ping Ong [email protected] wrote:

@utf https://github.com/utf I have been asking MP to change the simulation scheme for some time. In my view, the protocol should be: i. Relax with low kpoints. ii. Relax with denser kpoints and EDIFF=1e-4 (at least) and EDIFFG=-0.05. ISMEAR=1 if step i is zero gap. iii. If vol change > 10%, repeat. iv. Static with Gamma k-points and ISMEAR=-5. ....all other simulations from this point.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/hackingmaterials/atomate/issues/277#issuecomment-476376643, or mute the thread https://github.com/notifications/unsubscribe-auth/AC1rREvFFWdMKofhr-UWHwVpEeNWpBGzks5vaTm2gaJpZM4cIkPt .

[utf]

Agree with all of that. Especially using a negative value of EDIFFG, a tighter EDIFF, and repeated relaxations on volume change.

[shyuep]

@mkhorton Well, the "low" kpoint in step 1 is optional I guess. I would say the default in pmg is already very low (being written in 2011/2012) and seems to be relatively stable. The question then is whether you do relaxation No. 2+ with a higher k mesh. Again, I think this can be a gap/no-gap distinction. If gapped -> continue with same kpoint as step 1 (or maybe a bit higher?). If metal, you need to seriously crank up the k-points with ISMEAR=1.

[shyamd]

Question is, is the metal/non-metal distinction the responsibility of custodian or the workflow/researcher?

[shyuep]

@shyamd For low-throughput, it is clearly the responsibility of researcher. For HT, we need a classification strategy. There is a priori and a posteriori classification. For a priori, you can use a ML algo, e.g., the MEGNet models can predict a pretty good metal/non-metal classifcation, but so can a lot of other models. For a posteriori, we can rely on an initial "scratch" run, which is essentially what relaxation no. 1 is, and use that to set the approach for subsequent runs.

[mkhorton]

My first-pass opinion is that it's the responsibility of atomate -- e.g. pymatgen could have both an MP*MetalSet and an MP*NonMetalSet, atomate should choose the correct one dynamically after the initial ('scratch') relaxation. This also then makes it explicit to users who only use pymatgen that they need to make an active choice here too. I'm open to other opinions on this however. I'm not sure that custodian should be involved necessarily.

[utf]

My concern is, after the initial relaxation, how many parameters will be different between the metal and non-metal sets? It seems to me that there won't be many (if any) differences, other than the default k-point density?

[ardunn]

@dyllamt you may want to check the NEDOS value also, I think this is too low.

@mkhorton above picture is with NEDOS=10000 iirc. Should it be turned higher?

[shyuep]

@utf There are only a few differences. Basically k-point density, ISMEAR and SIGMA. Certainly, there is nothing preventing us from implementing this entirely using user_incar_settings and user_kpoints_settings, but it would be less pedagogical for users.

Perhaps let me propose a concrete section of actions: i. I will add a MPMetalRelaxSet, which is simply a subclass of MPRelaxSet but with recrp_density set at 200 and ISMEAR=1 and SIGMA=0.2 (any objections)? I don't think we need a separate MPNonMetalRelaxSet. I can certainly add it, but it will be no different from MPRelaxSet. ii. Someone should bring this up at MP meeting and discuss changes to the atomate relaxation workflow to implement the above changes (multi-step, dynamic setting of ISMEAR, etc.) Then someone needs to implement those changes.

[mkhorton]

@ardunn Ah, no, that should be plenty. And this is with tetrahedral integration, or is it not? @utf said he changed the input set in pymatgen a while back.

[ardunn]

@mkhorton Correct, this is with ISMEAR=-5

@mkhorton Revision: Actually just double checked, ISMEAR is being changed to 0 somewhere (we set -5 trying to override, but it's changed to gaussian!?!)

@mkhorton the trouble in setting this ISMEAR comes from issue similar to #268

[shyuep]

https://github.com/materialsproject/pymatgen/commit/1da439a5695de7cca930649159fb25e4135b2b96