Describe the bug
VaspInputGenerator (atomate2/vasp/sets/base.py) redeclares structure as a plain dataclass field. This shadows (overrides) the structure property pymatgen's VaspInputSet defines for that same name — the property whose setter applies sort_structure, reduce_structure, and validate_magmom. Because the child class's plain field is found first, self.structure = ... never reaches that setter, so structures are not sorted for every atomate2 VASP input-set generator (relax, static, MD, ...).
This is invisible for generators whose INCAR doesn't depend on POSCAR atom-type ordering. It is not invisible for MDSetGenerator's npt ensemble: LANGEVIN_GAMMA is sized to the number of distinct elements, but VASP counts POSCAR "types" as contiguous same-element runs. If the input structure isn't already grouped by element, the two counts diverge and VASP aborts immediately with:
Error reading item LANGEVIN_GAMMA from file INCAR. IERR= 5
I REFUSE TO CONTINUE WITH THIS SICK JOB ... BYE!!!
To Reproduce
Steps to reproduce the behavior:
- Build a
Structure whose same-element sites are not contiguous (e.g. built cluster-by-cluster rather than grouped by element).
- Pass it to
MDSetGenerator(ensemble="npt").get_input_set(structure, potcar_spec=True).
- Compare
len(vasp_input["POSCAR"].natoms) (atom-type count VASP will see) to len(vasp_input["INCAR"]["LANGEVIN_GAMMA"]) (values VASP will get) — they differ.
- Running the generated input through VASP produces the fatal error above.
A minimal, runnable repro is attached: shadow_example.py. It asserts the two counts are equal — it fails today, and would pass if sort_structure actually ran.
Expected behavior
With sort_structure=True (the default), the structure should be sorted (grouping same-element sites into contiguous POSCAR blocks) before POSCAR/INCAR generation, exactly as pymatgen's VaspInputSet docstring promises. LANGEVIN_GAMMA's length should then always match VASP's parsed atom-type count.
Screenshots
Not applicable (not a UI issue) — the VASP fatal error text above is the observable symptom.
Describe the bug
VaspInputGenerator(atomate2/vasp/sets/base.py) redeclaresstructureas a plain dataclass field. This shadows (overrides) thestructureproperty pymatgen'sVaspInputSetdefines for that same name — the property whose setter appliessort_structure,reduce_structure, andvalidate_magmom. Because the child class's plain field is found first,self.structure = ...never reaches that setter, so structures are not sorted for every atomate2 VASP input-set generator (relax, static, MD, ...).This is invisible for generators whose INCAR doesn't depend on POSCAR atom-type ordering. It is not invisible for
MDSetGenerator'snptensemble:LANGEVIN_GAMMAis sized to the number of distinct elements, but VASP counts POSCAR "types" as contiguous same-element runs. If the input structure isn't already grouped by element, the two counts diverge and VASP aborts immediately with:To Reproduce
Steps to reproduce the behavior:
Structurewhose same-element sites are not contiguous (e.g. built cluster-by-cluster rather than grouped by element).MDSetGenerator(ensemble="npt").get_input_set(structure, potcar_spec=True).len(vasp_input["POSCAR"].natoms)(atom-type count VASP will see) tolen(vasp_input["INCAR"]["LANGEVIN_GAMMA"])(values VASP will get) — they differ.A minimal, runnable repro is attached: shadow_example.py. It asserts the two counts are equal — it fails today, and would pass if
sort_structureactually ran.Expected behavior
With
sort_structure=True(the default), the structure should be sorted (grouping same-element sites into contiguous POSCAR blocks) before POSCAR/INCAR generation, exactly as pymatgen'sVaspInputSetdocstring promises.LANGEVIN_GAMMA's length should then always match VASP's parsed atom-type count.Screenshots
Not applicable (not a UI issue) — the VASP fatal error text above is the observable symptom.