Open naik-aakash opened 2 months ago
did you specify gamma_vasp_cmd
? it only auto-switches if it finds the vasp gamma executable and the default name it looks for isn't great since afaik it's more commonly named vasp_gam
, not self.vasp_cmd + ".gamma"
KSPACING
is the important point. We currently don't see how the code is accounting for this.
KSPACING
is the important point. We currently don't see how the code is accounting for this.
Right, IIRC when KSPACING
is set, then kpts
is None
and so the check quoted above would fail.
did you specify
gamma_vasp_cmd
? it only auto-switches if it finds the vasp gamma executable and the default name it looks for isn't great since afaik it's more commonly namedvasp_gam
, notself.vasp_cmd + ".gamma"
Hi @janosh , yes, I did set the gamma_vasp_cmd
in the atomate2 config file, and atomate2 is able to use the gamma version automatically when I do not set KSPACING
in the INCAR (this results in the KPOINTS file being explicitly generated). Issue occurs only when KSPACING
is set.
@naik-aakash @janosh: we'd need to add either a handler to check for when the KSPACING-generated k-points is 1x1x1 and centered at $\Gamma$, or use this formula from the VASP manual to estimate the k-point grid before running VASP
Code snippet
No response
What happened?
Expected behaviour
vasp_gam version should be used instead of VASP std.
Potetial fix
Adapt the checks on the following line https://github.com/materialsproject/custodian/blob/880ca8b96ec3adfe57497b4cba1b72242db8be83/src/custodian/vasp/jobs.py#L245
Version
2024.6.24
Which OS?
Log output
No response