[BUG]: Tetrahedron method not properly fixed with 1x1x1 k-points

[Andrew-S-Rosen]

Problem

When using ISMEAR=-5 with NKPT<4, VASP crashes with the following error:

 -----------------------------------------------------------------------------
|                                                                             |
|     EEEEEEE  RRRRRR   RRRRRR   OOOOOOO  RRRRRR      ###     ###     ###     |
|     E        R     R  R     R  O     O  R     R     ###     ###     ###     |
|     E        R     R  R     R  O     O  R     R     ###     ###     ###     |
|     EEEEE    RRRRRR   RRRRRR   O     O  RRRRRR       #       #       #      |
|     E        R   R    R   R    O     O  R   R                               |
|     E        R    R   R    R   O     O  R    R      ###     ###     ###     |
|     EEEEEEE  R     R  R     R  OOOOOOO  R     R     ###     ###     ###     |
|                                                                             |
|     IBZKPT: tetrahedron method fails for NKPT<4. NKPT = 1                   |
|                                                                             |
|       ---->  I REFUSE TO CONTINUE WITH THIS SICK JOB ... BYE!!! <----       |
|                                                                             |
 -----------------------------------------------------------------------------

The solution in this case should be to update ISMEAR to 0 (and set SIGMA to 0.05). However, that's not done.

Instead, Custodian tries to increase the number of k-points by 20% here:

custodian/custodian/vasp/handlers.py

Lines 202 to 204 in bc9ecbb

	# increase KPOINTS by 20% in each direction (approximately double no. of kpoints)
	new_kpts = tuple(int(round(num * 1.2, 0)) for num in vi["KPOINTS"].kpts[0])
	actions.append({"dict": "KPOINTS", "action": {"_set": {"kpoints": (new_kpts,)}}})

There are two issues with this approach:

1. It just plain doesn't work. If you have 1x1x1 k-points, the 20% increase will change it to 1.2x1.2x1.2, which rounds right back down to 1x1x1. This is a silly exercise. You are only hitting the "tet" error with a small number of k-points, so it's always going to round back down.
2. We really should not be modifying k-points on-the-fly unless this is some last resort. The k-points, like ENCUT, are effectively part of the level of theory being applied here and we should not be changing it so freely. Edit: This is more of a personal opinion, and @esoteric-ephemera has convinced me that we can live with this.

This behavior was a breaking change introduced in #284.

---

@janosh: I saw you referred to https://vasp.at/forum/viewtopic.php?f=3&t=416&p=4047&hilit=dentet#p4047 in your PR. If you'd like to handle the "dentet" error differently, that's fine, but it should not impact the "tet" error handler in any way. I also am hesitant about updating the number of k-points in general. I would recommend trying to increase NEDOS, as mentioned in the forum, before considering any changes to the number of k-points with the dentet error. In any case, that is secondary to the main issue reported here.

[janosh]

thanks for catching this! it's not visible on GitHub but @esoteric-ephemera and i were pair-programming at the time so in that sense there was a reviewer on PR #284 (i'm not versed enough in VASP automatic error handling to design such "fixes" myself). though apparently we still fell short of due diligence

[Andrew-S-Rosen]

Noted, thanks! I think the problem here boils down to trying to handle two different issues simultaneously, as "tet" will always have very small number of k-points (e.g. 1x1x1) so the fix won't work.

[esoteric-ephemera]

I posted some preliminary thoughts on #336.

Our fix doesn't work because we used round instead of ceil. Using ceil, the k-point density would be updated accordingly. I'm not sure that changing smearing first is preferable

[Andrew-S-Rosen]

Also, my apologies to @janosh and @esoteric-ephemera. I realize in hindsight that my original post likely came off as argumentative, and that is on me. Sleep deprivation took its toll, and I should have been more cognizant of that.