Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BUG: Potential incompatibility with "old" MP GGA workflow w.r.t. k-points in GGA static calculations #844

Closed
Andrew-S-Rosen opened this issue May 12, 2024 · 2 comments

Comments

@Andrew-S-Rosen
Copy link
Member

Andrew-S-Rosen commented May 12, 2024

In Pymatgen, the MPStaticSet has a reciprocal_density of 100, as shown here. This overrides the default value of 64 in the MPRelaxSet.yaml. However, in atomate2, the MPGGAStaticSetGenerator does not seem to change the default of 64 to 100.

I'm not sure if I'm missing this somewhere, but that's a potential incompatibility. One would have to dig through atomate1 to be 100% certain (or compare against structures on MP). Note: This bug report was pulled from a larger comment in #724 since I felt it was important to distinguish it.

Tagging @esoteric-ephemera.

from pymatgen.core import Structure
from atomate2.vasp.jobs.mp import MPGGAStaticMaker

s = Structure(
    lattice=[[0, 2.13, 2.13], [2.13, 0, 2.13], [2.13, 2.13, 0]],
    species=["Ni", "O"],
    coords=[[0, 0, 0], [0.5, 0.5, 0.5]],
)
kpts = MPGGAStaticMaker().input_set_generator.get_input_set(s, potcar_spec=True).kpoints.kpts[0]
print(kpts) # (9, 9, 9)
from pymatgen.core import Structure
from pymatgen.io.vasp.sets import MPStaticSet

s = Structure(
    lattice=[[0, 2.13, 2.13], [2.13, 0, 2.13], [2.13, 2.13, 0]],
    species=["Ni", "O"],
    coords=[[0, 0, 0], [0.5, 0.5, 0.5]],
)
kpts = MPStaticSet(s).kpoints.kpts[0]
print(kpts) # (10, 10, 10)
@Andrew-S-Rosen Andrew-S-Rosen changed the title BUG: Potential incompatibility with "old" MP GGA workflow BUG: Potential incompatibility with "old" MP GGA workflow w.r.t. k-points in GGA static calculations May 12, 2024
@JaGeo
Copy link
Member

JaGeo commented May 12, 2024

Thanks for pointing this out. We in our group mostly adapt the sets for our runs and therefore don't notice such problems. Especially for future MP production runs, however, this might be highly important.

@esoteric-ephemera
Copy link
Contributor

Thanks for pointing this out! While we'll eventually use KSPACING in lieu of KPOINTS for MP production runs, this has to be fixed for legacy MP workflows. I'm currently working on getting the sets ported to PMG and should probably put the draft PR for that up soon

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants