MPNonSCFSet k-point generation incompatible with tetrahedron smearing

[utf]

Currently, MPNonSCFSet with mode=uniform creates an explicit list of k-points using SpacegroupAnalyzer.get_ir_reciprocal_mesh. As this list of k-points does not include tetrahedron information, the generated k-points file is incompatible with setting ISMEAR = -5. A recent update to the MPNonSCFSet set the default smearing parameter to ISMEAR = -5, so all uniform NSCF jobs in atomate are currently failing. See hackingmaterials/atomate#283.

Is there a reason for generating the list of k-points manually rather than letting VASP automatically generate the k-points based on a mesh size (e.g., 3x3x3)? VASP will automatically add the tetrahedron information when ISMEAR = -5, so this issue is avoided.

I really can't see the benefit of EVER generating the list of k-points manually, except for line-mode band structures but maybe I am missing something?

[hautierg]

This was a while ago but I remember that the reason we went for explicit generation of k-points is symmetry. VASP uses a certain way of setting symmetries that is sometimes incompatible with other assignment for instance in spglib and from what I remember not super clear from the source code. That means spglib will tell you a certain k-point mesh in the irreducible brillouin zone and VASP another one. When you want to do things outside VASP (I think Boltztrap treatment was one example this would lead to inconsistencies). The MPNonSCFSet method was never intended to be used with the tetrahedron method and I think it used to not set ISMEAR=-5. But as I said this was a while ago for specific purpose and if we want to switch to something else I am fine with it. However, we should keep this issue of symmetry in mind. Geoffroy On 01 May 2019, at 20:20, Alex Ganose <[email protected]<mailto:[email protected]>> wrote: Currently, MPNonSCFSet with mode=uniform creates an explicit list of k-points using SpacegroupAnalyzer.get_ir_reciprocal_mesh. As this list of k-points does not include tetrahedron information, the generated k-points file is incompatible with setting ISMEAR = -5. A recent update to the MPNonSCFSet set the default smearing parameter to ISMEAR = -5, so all uniform NSCF jobs in atomate are currently failing. Is there a reason for generating the list of k-points manually rather than letting VASP automatically generate the k-points based on mesh size (e.g., 3x3x3)? VASP will automatically add the tetrahedron information when ISMEAR = -5, so this issue is avoided. I really can't see the benefit of EVER generating the list of k-points manually, except for line-mode band structures but maybe I am missing something? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#1453>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AAG6L52TV7MBQVFEY7QGILLPTHNNPANCNFSM4HJVJD2A>.

[fraricci]

I think one of the reason was to avoid problems in using boltztrap1.
Using a list of kpoints generated by spglib in KPOINTS will be compatible
with the list of symmetry operations (again from with spglib ) provided as input of boltztrap1.

If we let VASP decide the kpoints, then spglib could give different sym ops and you get a
famous "error in factorization".

I am not sure this is still necessary for running boltztrap 2. I'll check that.

[fraricci]

IMHO, changing the ISMEAR default was not the best move.
If the intention was to have input file for DOS calculation,
it could be much better to add a new 'dos' mode to MPNonSCFSet and
keep 'uniform' and 'line' doing what they have done since ever.
Consider also that custom incar parameter can be passed both in pmg and atomate.

[mkhorton]

I imagine this depends whether NonSCFSet is used more for DOS or for BoltzTraP? I imagine most people using it in uniform mode want to calculate a DOS.

[fraricci]

you said it, 'imagine'. Since we do not know, I would go safe adding a new feature than break a old.
That's IMHO ;-)

[utf]

Thanks for the information @hautierg and @fraricci. I can see why those settings were chosen.

Going forward, I think the default behavior of MPNonSCFSet should be compatible with as many VASP smearing parameters as possible. It is perfectly reasonable that a user would want to use ISMEAR = -5 for an NSCF calculation, whether it is a uniform or optics calculation (tetrahedron smearing is recommended for optics calculations anyway.)

To me, the boltztrap behavior should have its own mode as this is a non-standard VASP workaround.

[fraricci]

yes, I agree. The current 'uniform' mode could become 'boltztrap'. And new mode 'dos' and/or 'optics' could be added.

[mkhorton]

@fraricci your suggestion has been implemented by @utf and merged, thanks for the discussion!

[fraricci]

I think I found an important bug in the current "uniform" mode.
ISYM = 0 remained from previous behavior now implemented as "boltztrap" mode.

When someone sets "uniform" mode, he want VASP to produce the k-points according
to a certain mesh and the use of symmetries has to be enabled (ISYM=1) to get those k-points only in the irreducible BZ. Now, with ISYM=0, symmetries are disabled and the kpoints are generated in the whole BZ.

This can affect the accuracy of the calculation in "uniform" mode. An example is
all the properties from Boltztrap (transport, bands, doses).

All the calculation done with pmg versions since May 9 have this bug.

@utf could you double check this?

[mkhorton]

Also tagging @munrojm here.

[utf]

Hi @fraricci

Thanks for flagging this! As far as I can tell, the changes adding the tetrahedron method to the NonSCF set (added in PRs #1382 and #1458) didn't change any of the symmetry settings, unless I'm missing something.

I'm not sure how this affects the accuracy of Boltztrap properties as symmetry was always disabled for Boltztrap calculations? For "uniform" calculations, the lack of symmetry shouldn't affect the accuracy but means that the computational expense will have been unnecessarily higher.

I'd be in favor of turning on symmetry for "uniform" mode, unless anyone has any reason not to. Do you think we should also enable it for "boltztrap" mode?

[fraricci]

In "boltztrap" mode symmetry has to be disabled because the kpoints are provided by spglib already in the irreducible BZ. So, ISYM=0 is the correct choice for this mode.

For "uniform" mode symmetry has to be ON: ISYM=1 or removed from the incar.
Because we want VASP to generate the kpoints in the irr-BZ.

About the accuracy you are right. For a given mesh, the number of irreducible kpoints is the same in both cases ISYM=0,1. Therefore, as you said the only problem is the computational expense: with ISYM=0 more kpoint are calculated even they are not necessary.