Lattice dynamics workflow using Pheasy

[hrushikesh-s]

Summary

Include a summary of major changes in bullet points:

• Feature 1
• Fix 1

Additional dependencies introduced (if any)

• List all new dependencies needed and justify why. While adding dependencies that bring
  significantly useful functionality is perfectly fine, adding ones that add trivial
  functionality, e.g., to use one single easily implementable function, is frowned upon.
  Justify why that dependency is needed. Especially frowned upon are circular dependencies.

TODO (if any)

If this is a work-in-progress, write something about what else needs to be done.

• Feature 1 supports A, but not B.

Checklist

Work-in-progress pull requests are encouraged, but please put [WIP] in the pull request
title.

Before a pull request can be merged, the following items must be checked:

• Code is in the standard Python style.
  The easiest way to handle this is to run the following in the correct sequence on
  your local machine. Start with running ruff and ruff format on your new code. This will
  automatically reformat your code to PEP8 conventions and fix many linting issues.
• Doc strings have been added in the Numpy docstring format.
  Run ruff on your code.
• Type annotations are highly encouraged. Run mypy to
  type check your code.
• Tests have been added for any new functionality or bug fixes.
• All linting and tests pass.

Note that the CI system will run all the above checks. But it will be much more
efficient if you already fix most errors prior to submitting the PR. It is highly
recommended that you use the pre-commit hook provided in the repository. Simply run
pre-commit install and a check will be run prior to allowing commits.

[JaGeo]

Suggested change

	# Here, the ALAMODE copde is used to determine the number of
	# Here, the ALAMODE code is used to determine the number of

[JaGeo]

Suggested change

# TODO: potentially add kwargs to avoid computation of eigenvectors

[JaGeo]

Linking this issue again #1208

[esoteric-ephemera]

@JaGeo if you have a suggestion for how to implement the kind of check in #1208, feel free to push later today. Need to make some updates to the test data (there are absolute tolerances of 1000 used so the data is unreliable), don't unfortunately have the bandwidth to add a check like you're describing

[JaGeo]

@esoteric-ephemera Sure. No worries. I just wanted to mention this again as a potential source for problems. This can be left out for now. (I also don't have the bandwidth)

[esoteric-ephemera]

Also: one of the bigger changes in the phonon schema in going from atomate2 to emmet is to make the temperature, free energy, heat capacity, and entropy on-the-fly computed fields. The rationale was that these are really just computed from the phonon DOS, which we already store, and are fast to compute

I see that a lot of the phonon-derived flows (QHA + Gruneisen) require stored temperature + phonon DOS derived data, which also seems like a bad idea given that the default grid in the older PhononBSDOSDoc was very coarse (100 K steps)

I was able to get the Gruneisen flow working with just an additional job analysis step, for QHA I'll need to add another document model to store the thermal outputs, since the original phonopy test data also omits DOSes

[JaGeo]

@esoteric-ephemera Thanks for the feedback. We have added QHA and Grüneisen workflows quite recently and both have not been heavily tested in production yet. Thus, default values have not been optimized. I am also sorry that it requires a lot of effort from your side to integrate the document models from emmet into atomate2. However, at the time of development, the future developments for the phonon workflow were not yet clear.

[esoteric-ephemera]

No worries! For now then, I'll go with making a slightly different phonon output data structure for QHA which saves some DOS-derived data, and then we can figure out better defaults later

[JaGeo]

@esoteric-ephemera Sure and thanks!