Phonons for forcefields

[JaGeo]

Summary

Closes #371 (in the future). It's a work in progress.

Plans:

• move more phonon job parts in common
• generalize the phonon jobs and schema

This is a first output for Si of the workflow with CHGNet:

We will also validate the results carefully.

[codecov]

Codecov Report

Merging #398 (57fa7a4) into main (a89e6be) will increase coverage by 0.16%.
Report is 1 commits behind head on main.
The diff coverage is 79.45%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #398      +/-   ##
==========================================
+ Coverage   65.32%   65.48%   +0.16%     
==========================================
  Files          74       78       +4     
  Lines        7189     7437     +248     
  Branches      930      961      +31     
==========================================
+ Hits         4696     4870     +174     
- Misses       2209     2267      +58     
- Partials      284      300      +16     

Files Changed	Coverage Δ
src/atomate2/forcefields/flows/relax.py	62.06% <ø> (ø)
src/atomate2/forcefields/flows/phonons.py	65.38% <65.38%> (ø)
src/atomate2/forcefields/utils.py	73.91% <73.91%> (ø)
src/atomate2/common/schemas/phonons.py	97.12% <84.61%> (ø)
src/atomate2/common/jobs/phonons.py	84.88% <91.66%> (ø)
src/atomate2/forcefields/jobs.py	92.43% <93.58%> (+2.60%)	⬆️
src/atomate2/forcefields/flows/__init__.py	100.00% <100.00%> (ø)
src/atomate2/forcefields/schemas.py	91.66% <100.00%> (-2.62%)	⬇️
src/atomate2/vasp/flows/phonons.py	89.24% <100.00%> (ø)

... and 1 file with indirect coverage changes

[JaGeo]

@gpetretto FYI. @QuantumChemist and I will work on this implemention in the next 1-2 months.

[JaGeo]

Closes #409 as well.

[JaGeo]

I have added the force constants to the data store as well.

[x] Tests for the workflow
[x] Tests for new calculators etc. I have now added a forcefield calculator based on GAP potentials and some general methods to allow for easy addition of new forcefield calculators based on ase. I also need to change to numpy doc style.
[x] an assessment if we can provide a common workflow. One issue for generalization are the BORN charges. Currently, there is a very VASP specific way to read them and we cannot compute them with force fields. My current assessment is that we should make a separate discussion on this.
[x] Check convergence criteria for optimization and static runs (tight enough?), run more complex structures. (Partially done but potentially more tests)
[x] General forcefield document that would work for any calculator from ase (e.g., EMT).
[x] Move some more phonon to common
[x] Switch off default eigenvector generation and thermal_displacements to reduce storage requirements
[x] Move all displaced structures to the datastore (can be very large for large cells without symmetry)

[JaGeo]

For Mg3Sb2, the phonon band structures show imaginary modes. However, this might potentially be expected. Overall still close results to DFT:

ZnS looks still kind of reasonable 😉 (no BORN charges, but still)

[JaGeo]

@utf and maybe also @gpetretto: maybe you have some thoughts with regard to generalization. As mentioned above, BORN charges and potentially also relying on previous DFT computations are an issue for generalization of the workflow.

E.g., this line: https://github.com/JaGeo/atomate2/blob/ae043eb0d321ad630e4593dd68bc6a0042ebbe6e/src/atomate2/vasp/flows/phonons.py#L314

or this line:
https://github.com/JaGeo/atomate2/blob/ae043eb0d321ad630e4593dd68bc6a0042ebbe6e/src/atomate2/vasp/flows/phonons.py#L240

[JaGeo]

I will potentially finish the workflow including tests for the forcefield part for now. Then, we really need to do a discussion on how "common" workflows where several DFT/force field runs are included should be generalized.

I could define abstract methods for born charge computation, bulk relaxation, static runs that we than overwrite for each specific code. "prev_vasp_dir" is one of the issues that require this.

Or we could come up with a general way of connecting jobs ("prev_dir"). This would then, however, require a lot of refactoring and also a lot of thinking.

[JaGeo]

I adapted my work plan a bit. Some parts could also be included within another PR.

[utf]

Thanks very much for this @JaGeo. I think we can leave the discussion for merging the vasp and forcefield phonon workflows to a separate PR. I have some ideas for this which I can raise in an issue.

I put a couple of very minor comments on the PR. Can you also rename atomate2/forcefields/flows/flows.py to atomate2/forcefields/flows/relax.py and import the two classes in that file in atomate2/forcefields/flows/__init__.py to avoid any breaking changes.

[JaGeo]

Thanks.
Could you make the comments public? I don't see them yet.

[utf]

Remove?

[utf]

Remove?

[JaGeo]

@utf , merge conflicts and your suggestions should be addressed! I hope it is ready to merge!

[utf]

Fantastic. Thanks very much!