dont write kpoints file

[Leimeroth]

Bcause it is possible to use KSPACING in INCAR and I have to calculate some data in a consistent manner with that setting so I need an option to not write the KPOINTS file.

This is an ugly workaround so I am open to other suggestions. Also it does not get stored in hdf, but the hdf storage of GenericParameters looks mysterious to me and I didn't want to put too much effort into the ugly workaround.

[pmrv]

Vasp.set_kpoints() allows for k_mesh_spacing, but we calculate the k-points on our own in this case. Is it possible for you to use this or do you want to use strict consistency with calculations performed outside pyiron? If so does it make sense to drop our calculation and just use KSPACING from set_kpoints, @sudarsan-surendralal ?

[coveralls]

Pull Request Test Coverage Report for Build 1966145612

• 3 of 3 (100.0%) changed or added relevant lines in 1 file are covered.
• 1 unchanged line in 1 file lost coverage.
• Overall coverage decreased (-0.002%) to 70.462%

---

Files with Coverage Reduction	New Missed Lines	%
pyiron_atomistics/lammps/structure.py	1	75.08%

Totals
Change from base Build 1949215033:	-0.002%
Covered Lines:	11851
Relevant Lines:	16819

---

💛 - Coveralls

[Leimeroth]

Is it possible for you to use this or do you want to use strict consistency with calculations performed outside pyiron?
I need to keep calculations strictly consistent.

I think vasp calculates it differently from pyiron, so I think keeping the k-point calculation on the pyiron side is the better option to compare between different codes.

[sudarsan-surendralal]

Is it possible for you to use this or do you want to use strict consistency with calculations performed outside pyiron?
I need to keep calculations strictly consistent.

I think vasp calculates it differently from pyiron, so I think keeping the k-point calculation on the pyiron side is the better option to compare between different codes.

Yes, you are right (see here) they are not 100% equivalent. Although the "pyironic" way is to do what @pmrv suggested, this won't be consistent with your other calculations. So I guess we have to use a workaround like you implemented.

[sudarsan-surendralal]

It would be nice to write a simple unittest for jobs like this to check it it works (some examples here). Additionally, we should warn users when 'KSPACING' is there in the INCAR file but a KPOINTS file is also present

[pmrv]

lgtm.

EDIT: I defer to @sudarsan-surendralal on the unit tests issue, not sure how and where to do that best, but I guess making a job with run_mode='manual' and then checking input files written should be possible.

[sudarsan-surendralal]

LGTM! I added a unit test for this and it works.

[Leimeroth]

LGTM! I added a unit test for this and it works.

Thanks