Import MP input sets directly from Pymatgen

[Andrew-S-Rosen]

Right now, we have duplication of information between pymatgen and atomate2. With materialsproject/pymatgen#3484, there are no remaining blockers to using pymatgen sets in atomate2. At some point, atomate2 should make the switch to complete the transition.

While I won't be orchestrating the transition, I wanted to jot down a few scattered thoughts and potential "gotchas" when Atomate2 transitions to using Pymatgen input sets.

CC @esoteric-ephemera, @utf

GGA workflow

k-points for metals

The Pymatgen MPRelaxSet.yaml has the following:

KPOINTS:
  reciprocal_density: 64

However, the atomate2 BaseMPGGASet.yaml has the following:

KPOINTS:
  reciprocal_density: 64
  reciprocal_density_metal: 200

This is because the reciprocal_density_metal logic exists only within atomate2. When switching to the Pymatgen YAML, you'll likely need to account for this missing parameter.

Of note, the Pymatgen MPStaticSet class has a small_gap_multiply kwarg that can handle this.

k-points in static runs

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 pre-existing incompatibility? [Now raised in https://github.com//issues/844].

r2SCAN workflow

YAMLs

As of materialsproject/pymatgen#3615, the r2SAN YAMLs should be the same in both Atomate2 and Pymatgen, so you should be able to do a clean swap without issues.

That said, the auto_ismear setting is set to True by default in MPScanRelaxSet in Pymatgen, whereas in atomate2 it is set to False by default.

Other comments

The LAECHG and LVTOT parameters are both set to True in the MPScanRelaxSet.yaml (same for the analogue in atomate2). This seems like something that should be False for relaxations and enabled to True for statics. In the past, I do know LAECHG = True was inaccurate for relaxations anyway, as noted by Tom Manz in his Chargemol documentation. I'm not sure if that was ever patched.