emmet 0.86.1 compatibility

[esoteric-ephemera]

Get atomate2 up to date with changes in emmet-core>0.86.0

• Adds toggles for using newer emmet-core models for large data obejcts (trajectories, charge densities, etc.) vs pymatgen models. pymatgen still is the default
• Remove python 3.10 support, close DISCUSSION: deprecate python 3.10 support? #1334

[esoteric-ephemera]

TODO: pin minimum emmet-core>=0.86.1rc0 once emmet #1345 is merged

[esoteric-ephemera]

Hey @JaGeo @utf do you have force merge permissions? I had to remove the py3.10 tests since some of the dependency stack now requires py>3.10, but the tests still show up here

[JaGeo]

@esoteric-ephemera not that i am aware of. I would assume we have the same permissions

@utf?

[utf]

I just updated the required tests to remove the Python 3.10 ones.

Just to confirm, will these new emmet models break compatability with old task documents referencing the previous objects? E.g., BandStructure?

If not, I'm happy for you to merge.

[esoteric-ephemera]

Just to confirm, will these new emmet models break compatability with old task documents referencing the previous objects? E.g., BandStructure?

It unfortunately will break that backwards compatibility without further changes. Two things to be aware of:

• All derived data in MP is being built with CoreTaskDoc and RelaxTrajectory objects. The CoreTaskDoc is a subset of the full atomate2 TaskDoc, with RelaxTrajectory containing ionic / electronic step info
• CoreTaskDoc uses all emmet-based models for VASP data (CHGCAR-like stuff, bandstructures, DOS,...) which are built around parquet. These emmet models all have to / from pymatgen methods for interoperability

The split on CoreTaskDoc vs. TaskDoc does mean that I can preserve the pymatgen models in atomate2 if you'd prefer. This would be the non-breaking solution, I'll have to put out another emmet rc to do this

[JaGeo]

Non-breaking would be my preference. I think from the number of installations we see via pypi (>100,000), we need to expect that we already have many users and therefore should be very careful with breaking changes

[utf]

I agree with @JaGeo, lots of groups are now using atomate2 so breaking changes should be avoided. I wonder if it is too much hassle to have a setting that controls whether to use the new models?

[esoteric-ephemera]

OK I'll get on that next then - shouldn't be too challenging to add a global toggle for emmet development features. We might need add more of these toggles as time goes on so best to do this while differences are still minor

In the mean time, I can put out a version of atomate2 with an upper emmet-core pin so that users don't run into issues with workflows / CI will get unblocked. Does that sound OK? Would just be the non-breaking changes from this PR

[esoteric-ephemera]

Just noting that there are two toggles for using either the pymatgen or emmet core data models for VASP outputs, one on the emmet-core side, USE_EMMET_MODELS, and one on the atomate2 side, VASP_USE_EMMET_MODELS. Both can be set as an environment variables, and the default is to use the pymatgen ones

The changes spread across files are there because we're now pinning a minimum version of emmet-core

The last thing I will add is a toggle for the pymatgen/emmet-core trajectory models in the forcefield/ase jobs

[JaGeo]

@esoteric-ephemera That's great. Could you add this in the setup part of the documentation as well?

[esoteric-ephemera]

Need to wait for conda issues to be resolved before tests will pass:
conda/infrastructure#1254