Equation of state (EOS) workflows

[esoteric-ephemera]

Summary

• Added VASP and MLFF-compatible EOS workflows
  • Both families inherit from base classes in atomate2.common.flows.eos
  • For the VASP workflows, three families of EOS workflows have been added:
    • Base atomate 2 parameters (base)
    • Legacy MP parameters in atomate2.vasp.x.EOS.mp_legacy: taken from this paper and used in the atomate 1 implementation (see here and here)
    • Current MP-compatible GGA and meta-GGA workflows in atomate2.vasp.x.EOS.mp. These represent "tight" calculations but do not strive for the same level of computational complexity as the original atomate workflow, which is less adapted for high-throughput (e.g., k-point grid_density is excessively high, as shown in the SI of the above paper)
  • For the MLFFs, all currently-implemented MLFFs (CHGNet, M3GNet, and MACE), have pre-defined EOS workflows (atomate2.forcefields.eos)
• Tests just for the MP GGA jobs and flows, and all MLFF flows

[codecov]

Codecov Report

Attention: Patch coverage is 83.77660% with 61 lines in your changes are missing coverage. Please review.

Project coverage is 76.59%. Comparing base (031521d) to head (24991d6).
Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #623      +/-   ##
==========================================
+ Coverage   76.22%   76.59%   +0.37%     
==========================================
  Files          88       94       +6     
  Lines        7191     7567     +376     
  Branches     1051     1141      +90     
==========================================
+ Hits         5481     5796     +315     
- Misses       1393     1426      +33     
- Partials      317      345      +28     

Files	Coverage Δ
src/atomate2/forcefields/utils.py	84.00% <ø> (ø)
src/atomate2/forcefields/flows/eos.py	92.00% <92.00%> (ø)
src/atomate2/vasp/flows/eos.py	88.67% <88.67%> (ø)
src/atomate2/vasp/jobs/eos.py	84.78% <84.78%> (ø)
src/atomate2/common/jobs/eos.py	85.71% <85.71%> (ø)
src/atomate2/vasp/sets/eos.py	81.01% <81.01%> (ø)
src/atomate2/common/flows/eos.py	77.33% <77.33%> (ø)

[esoteric-ephemera]

Finished generalizing and testing the EOS workflows. In addition to the VASP workflows defined previously, I've added default MLFF workflows using the EOS template in atomate2.common.flows.eos.CommonEosMaker.

[utf]

Hi @esoteric-ephemera, this all looks great.

I had one question about the _store_transformation_information - you mention that this is due to a conflict with emmet/pydantic. Is there an issue we can track in this thread that is preventing removing this option?

[esoteric-ephemera]

Thanks @utf! Right the issue persists with pydantic 2.4.2, emmet-core 0.77.1, and monty 2024.2.2

The ML FF flows run fine with this _store_transformation_information = True, but if I run the VASP tests with it set to True, I get this stacktrace:

File "/Users/aaronkaplan/miniconda3/envs/eos/lib/python3.11/site-packages/jobflow/core/store.py", line 522, in get_output
    return find_and_resolve_references(
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/aaronkaplan/miniconda3/envs/eos/lib/python3.11/site-packages/jobflow/core/reference.py", line 487, in find_and_resolve_references
    return MontyDecoder().process_decoded(encoded_arg)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/aaronkaplan/miniconda3/envs/eos/lib/python3.11/site-packages/monty/json.py", line 561, in process_decoded
    return cls_(**d)
           ^^^^^^^^^
  File "/Users/aaronkaplan/miniconda3/envs/eos/lib/python3.11/site-packages/pydantic/main.py", line 164, in __init__
    __pydantic_self__.__pydantic_validator__.validate_python(data, self_instance=__pydantic_self__)
pydantic_core._pydantic_core.ValidationError: 1 validation error for TaskDoc
transformations
  Input should be a valid dictionary [type=dict_type, input_value=<pymatgen.alchemy.materia...e object at 0x2bfc96810>, input_type=TransformedStructure]
    For further information visit https://errors.pydantic.dev/2.4/v/dict_type

I haven't looked into it much but I think it's a simple issue with serialization on the monty side. Happy to look into it further (since this will also affect the elastic flow) and/or open an issue about this

[utf]

I think we just need to set the type for the transformations field to be Any and have done with it! Would you be willing to make that PR?

[esoteric-ephemera]

Yep that's been done in emmet PR #937!

The interesting thing is that TaskDoc.transformations isn't serialized at load. Maybe the serialization occurs when output references are resolved?

Without changing the typing in emmet-core, I found that popping the @class and @module keys from TransformedStructure.as_dict() fixed this too, so the issue is serialization happening somewhere (but not in emmet).

[utf]

Awesome, thanks @esoteric-ephemera. It's not clear to me what is causing this issue. I wonder whether the recent monty release could help fix this?

[esoteric-ephemera]

I don't think so - I'm already on the latest monty == 2024.2.2

Also: just to keep track of things, the same pydantic validation exception is thrown in the elastic flow, as in issue #607

[utf]

Thanks @esoteric-ephemera!