Harmonic lattice dynamics workflow using hiPhive - #1062
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1062 +/- ##
========================================
- Coverage 4.32% 3.85% -0.48%
========================================
Files 178 193 +15
Lines 12911 14710 +1799
Branches 1278 1476 +198
========================================
+ Hits 559 567 +8
- Misses 12321 14112 +1791
Partials 31 31
|
|
|
hrushikesh-s
changed the title
|
Oh I see. Thanks for sharing that info!
|
|
this looks very close to mergeable. anything i can do to help this over the finish line? |
Mirrors the merged pheasy workflow. Displacement generation, force assembly, band structure, DOS and the output document are unchanged. Only the force-constant fit differs: the four pheasy subprocess calls are replaced by a hiPhive cluster space fitted with trainstation, with the Huang and Born-Huang rotational sum rules applied. Anharmonic force constants, phonon renormalization and lattice thermal conductivity are left for a follow-up. Reuses the Si_pheasy reference data so both workflows are tested against identical DFT inputs.
8f6b299 to
a2cbd33
Compare
hrushikesh-s
changed the title
|
@JaGeo, this PR is ready for review. I rebuilt it on top of the pheasy workflow from #1063. The two now share everything except the force constant fit. That took the diff from 114 files down to 8, and it adds no new test data since the test reuses |
|
@hrushikesh-s thanks! Did you run a slightly larger test to ensure stability of the workflow? I will take a closer look in the next days |
Relaxed cells carry numerical noise that breaks hiPhive's orbit construction. Also pass the workflow symprec, which otherwise defaults to 1e-5.
- pair cutoff sits between neighbour shells so hiPhive accepts it - refit steps one shell in instead of reusing the same cutoff - clear error when the supercell supports no neighbour shell - default fit_method is lasso, matching pheasy
|
Thanks Janine. I ran a larger test as you suggested. I picked 14 materials from the Materials Project, two per crystal system. All of them already have pheasy phonons in the database. For each material, I compared three things. The test found four bugs in this PR. All four are fixed and pushed. -- The pair cutoff could land on a neighbour shell, which hiPhive rejects. It now sits in the gap between shells. hiPhive agrees with phonopy on 10 of the 14. It disagrees on HfS2, NaAuO2, and K2ZnSi3O8. Ti2Ag fails because a 2x2x2 supercell of its body centred cell gives a cutoff that reaches no neighbour shell. Everything else follows DFT pheasy phonons workflow -- same displacement count, same 0.01 A amplitude, same symprec. Full numbers attached: |
|
Thank you! That's very helpful Could you maybe add a hint to the documentation that the code is only tested on a smaller dataset so far? |
Runs the force field hiPhive workflow end to end with MACE-OMAT-0-medium. The materials are Materials Project entries that already have pheasy phonons, so the result can be checked against DFT. Fourteen are listed, two per crystal system. Seven of them finish in about six minutes on a laptop. Excluded from the nbmake CI job, like the pheasy notebook, since it downloads the potential and runs full workflows.
Docs now say the workflow is only tested on a small set so far, and point at the tutorial notebook. Moved the hiPhive section below the ALAMODE block, since cal_anhar_fcs belongs to pheasy, not hiphive.
|
Added the note about the limited testing of the hiphive workflow to the docs, and also added a tutorial notebook that reproduces the 14 material test set. |
| to those forces by regression. In this Workflow, we separate the harmonic phonon | ||
| calculations and anharmonic force constants calculations. To correct for |
| supercells with all atoms displaced by a larger amplitude (generally using 0.08 A) | ||
| are generated and accurate forces are computed for these structures. The third- | ||
| and fourth-order force constants are fitted from the same cluster space. |
There was a problem hiding this comment.
I understood that this was actually not the scope of the PR. Did you test this?
| with ALM(lattice, positions, numbers) as alm: | ||
| alm.define(1) | ||
| alm.suggest() | ||
| n_fp = alm._get_number_of_irred_fc_elements(1) # noqa: SLF001 | ||
|
|
There was a problem hiding this comment.
This is also required for hiphive?
|
@hrushikesh-s I believe this s nearly ready to merge. Could you clarify the documentation when it comes to higher order force constants? |
Docstrings were copied from pheasy and still described a 0.08 A anharmonic branch that this PR does not implement. Removed two unused anharmonic file keys, and noted why ALM sizes the displacement set.
|
@JaGeo, good catch on all three. These are fixed in the latest commit. The docstring was copied from the pheasy maker and never trimmed. It described an anharmonic branch that does not exist here. Nothing generates 0.08 A displacements, and nothing fits third or fourth order, so there was nothing to test. The docstring now says harmonic only and that anharmonic is deferred. On ALM, yes it is needed. It counts the irreducible second-order force constants for the supercell, and that sets how many displaced configurations to generate. Using ALM also keeps the displacement count the same as pheasy, which is what made the 14 material comparison meaningful. I added a comment saying this. |
|
@hrushikesh-s thanks. I will merge now. Great, no open phonon-related PRs! One more thing: is our preprint on the Pheasy database already included somewhere in the documentation? If not, should we add it? |
|
Thanks! on citing the database preprint -- it's not in the docs anywhere yet, so yes, let us add it. I was thinking the Pheasy section of docs/user/codes/vasp.md, next to the pheasy code paper citation. Is that fine, or do you recommend adding it in some other location? |
|
Sounds good for now. Potentially we could start with using duecredit as we do in pymatgen. |
|
Correction, we do already use it: https://github.com/materialsproject/atomate2/pull/1442/changes |
3 participants
Summary
Lattice dynamics workflow using hiPhive, rebuilt on top of the pheasy workflow merged in #1063.
The two workflows are now identical except for the force-constant fit. Displacement generation, force assembly with residual subtraction, band structure, DOS, thermal displacements and the output document are shared code paths. Only the fit differs. The four
pheasysubprocess calls are replaced by a hiPhive cluster space fitted with trainstation, with the Huang and Born-Huang rotational sum rules applied, which is what--rasr BHHdid on the pheasy side.The test reuses the
Si_pheasyreference data rather than adding its own. Both workflows are therefore validated against identical DFT inputs, and the diff adds no test data.Previous version of this PR was 114 files. This is 8.
Additional dependencies introduced (if any)
New
hiphiveextra. hiPhive is already a dependency of the pheasy extra, so this pins the same version.alamodeand the build toolchain are already installed in thetest-non-aseCI job, so the workflow file changes by one word.The
git+https://gitlab.com/jsyony37/hiphive.git@personaldependency from the old version of this PR is gone. That fork existed to patchhiphive/fitting/fit_methods.py, a module that no longer exists in any current hiPhive. Fitting moved to the separatetrainstationpackage, which depends on scikit-learn directly.Deferred
Anharmonic force constants, phonon renormalization, Grüneisen parameters, thermal expansion and lattice thermal conductivity are not in this PR. pheasy's
--fix_fc2has no hiPhive equivalent, so the anharmonic fit needs a design decision that is better made on its own.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:
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 willautomatically reformat your code to PEP8 conventions and fix many linting issues.
Run ruff on your code.
type check your code.
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 installand a check will be run prior to allowing commits.