materialsproject
Lattice dynamics workflow using Pheasy
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
ruffandruff formaton 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.
Codecov Report
Attention: Patch coverage is 0% with 612 lines in your changes missing coverage. Please review.
Project coverage is 3.95%. Comparing base (
42bc7b8) to head (a8f805a). Report is 19 commits behind head on main.
Additional details and impacted files
@@ Coverage Diff @@
## main #1063 +/- ##
========================================
- Coverage 4.32% 3.95% -0.38%
========================================
Files 178 192 +14
Lines 12911 14246 +1335
Branches 1278 1421 +143
========================================
+ Hits 559 564 +5
- Misses 12321 13651 +1330
Partials 31 31
| Files with missing lines | Coverage Δ | |
|---|---|---|
| src/atomate2/common/flows/phonons.py | 0.00% <0.00%> (ø) |
|
| src/atomate2/forcefields/flows/pheasy.py | 0.00% <0.00%> (ø) |
|
| src/atomate2/vasp/flows/pheasy.py | 0.00% <0.00%> (ø) |
|
| src/atomate2/common/jobs/pheasy.py | 0.00% <0.00%> (ø) |
|
| src/atomate2/common/flows/pheasy.py | 0.00% <0.00%> (ø) |
|
| src/atomate2/common/schemas/pheasy.py | 0.00% <0.00%> (ø) |
- Flaky Tests Detection - Detect and resolve failed and flaky tests
![codecov[bot] avatar](https://avatars.githubusercontent.com/in/254?v=4 "Published by a pub.dev verified publisher"){kind=small}
Pheasy workflow depends on Alamode. @janosh, can you pls help in installing Alamode via .github/workflows/testing.yml file?
no idea, never used or installed Alamode before. the best solution would be for them to publish pre-compiled wheels to PyPI so the code doesn't need to be re-compiled from scratch on every CI run as that's both slow and tends to be brittle
@naik-aakash set up a docker for https://github.com/autoatml/autoplex but it has been a massive amount of work. Before this, we did the compilation on the repo. The slowness was a real problem. But not sure it is realistic to get the wheels. To sum up: compilation on the repo might be a realistic and okay solution if it isn't too slow.
@janosh thank you for offering this.
I am unsure about the timescales for such solutions. We would like to have the workflow available as soom as possible due to the planned atomate2 paper.
In that case, @JaGeo & @naik-aakash can you pls help with the compilation of alamode on the repo? Also tagging in @leslie-zheng.
@naik-aakash set up a docker for https://github.com/autoatml/autoplex but it has been a massive amount of work. Before this, we did the compilation on the repo. The slowness was a real problem. But not sure it is realistic to get the wheels. To sum up: compilation on the repo might be a realistic and okay solution if it isn't too slow.
These are the exact commands to install Alamode:
1. conda install -c conda-forge numpy scipy h5py compilers “libblas=*=*mkl” spglib boost eigen cmake ipython mkl-include
2. git clone https://github.com/ttadano/ALM.git
3. cd ALM
4. python setup.py build
5. pip install -e .
Just add it to the workflow file. You can see how micromamba is used for installation here: https://github.com/materialsproject/atomate2/blob/3d55b2b56b2dfb938ab60b6deb198b8e682fcd7f/.github/workflows/testing.yml#L61
@JaGeo , The test fails because GH can't find FORCECONSTANTS file in the temp folder. However, when I run the same test locally, I am able to successfully run it. Can you pls help?
@hrushikesh-s I will try to look into it. Could you add all installation instructions to the documentation as well?
@hrushikesh-s Locally, it fails for me with exactly the same error. Are you sure you have the same pheasy, ALM and phonopy versions? I only have a force_matrix.pkl file in the last folder but no FORCE_CONSTANT file
I also got a numpy error. Something in the pheasy commands seems to go wrong.
@hrushikesh-s I will try to look into it. Could you add all installation instructions to the documentation as well? Yes.
Doing this now
@hrushikesh-s Locally, it fails for me with exactly the same error. Are you sure you have the same pheasy, ALM and phonopy versions? I only have a force_matrix.pkl file in the last folder but no FORCE_CONSTANT file
Checking this now
@hrushikesh-s Thank you for this pull-request. I have a list of TODOs:
- [x] Solve conflicts with the current main branch
- [x] Check if the tests run through here on github actions
- [x] Add a real test for the whole pheasy workflow (ML potential and VASP) (only see schema tests so far)
- [ ] Add new documentation
Let me know if you need help with individual parts.
@hrushikesh-s Thank you for this pull-request. I have a list of TODOs:
- [ ] Solve conflicts with the current main branch
- [ ] Check if the tests run through here on github actions
- [ ] Add a real test for pheasy (only see schema tests so far)
- [ ] Add new documentation
Let me know if you need help with individual parts.
Hi Janine, Could you please tell us more about the requirement of new document? @JaGeo thanks jiongzhi
@leslie-zheng you mean documentation? Just some info on the approach as a part of the docs. Happy to help you write it once the conflicts are solved and a new test is there.
@hrushikesh-s Thank you for this pull-request. I have a list of TODOs:
- [x] Solve conflicts with the current main branch
- [x] Check if the tests run through here on github actions
- [x] Add a real test for the whole pheasy workflow (ML potential and VASP) (only see schema tests so far)
- [ ] Add new documentation
Let me know if you need help with individual parts.
@JaGeo , can you pls check if the PR looks okay?
@hrushikesh-s I increased code reuse in the pheasy code. The other changes already look great!
What is missing:
- please add instructions for the installation in the documentation, please also add a small section in the documentation on the pheasy workflow
- please check all doc strings (vasp.pheasy and forcefield.pheasy) and check if you added all required parameters
- please add a test for the forcefield implementation
- please switch to alm installation via conda-forge which should make the installation more stable
- get rid of code duplication in common.jobs.pheasy and common.jobs.phonons
- [ ] We need to add the Pheasy reference to the documentation or the doc string of this PR: https://arxiv.org/abs/2508.01020
Linking this issue again https://github.com/materialsproject/atomate2/issues/1208
@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
@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)
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
@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.
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