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 named vasp_gam, not self.vasp_cmd + ".gamma"

custodian/src/custodian/vasp/jobs.py

Lines 127 to 130 in 880ca8b

	gamma_vasp_cmd (str): Command for gamma vasp version when
	auto_gamma is True. Should follow the list style of
	subprocess. Defaults to None, which means ".gamma" is added
	to the last argument of the standard vasp_cmd.

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

The VASP gamma code was written in the age before KSPACING was introduced. I am fine with adding logic to check for KSPACING and choosing the gamma version if it results in a 1x1x1 KPOINT. Someone would have to implement it though.