Phonons at temperature: the 0 K stability answer is often the wrong one

[Starlitnightly]

mv.prop.phonon_at_temperature fits, through hiphive, the effective harmonic force constants that best describe the potential energy surface sampled at a temperature — rather than expanding about the 0 K minimum.

obs["dynamically_stable_{level}"] from mv.prop.phonon is a statement about 0 K, and a great many real materials fail it and exist anyway. bcc metals and cubic perovskites are unstable in the harmonic approximation and held up by anharmonicity at the temperature they are actually used at. A screen that discarded them on the 0 K answer would be discarding the answer.

Three lattices, three answers

	50 K	300 K	600 K	900 K	verdict
bcc Cu	4	0	0	0	stabilised at 300 K
fcc Cu	0	0	0	0	nothing to stabilise
sc Cu	21	21	21	21	never stabilised in range

stabilisation_temperature is NaN for both fcc and sc, for opposite reasons, so uns[...]["verdict"] says which. A NaN meaning two opposite things is worse than no column, and a test asserts the two verdicts differ.

I nearly shipped a wrong conclusion

Lattice.cubic(2.9) with one atom is simple cubic, not bcc. On that structure the method looked erratic — 72 imaginary modes at 50 K, and a stabilisation temperature that moved from 900 K to 300 K on iteration count alone. I was about to report the method as unreliable.

It was the input that was wrong. With the real bcc primitive the answer is identical at 8 and 20 iterations, and a test now asserts that, so a genuine convergence failure would be visible rather than inferred.

Two diagnostics, because both change the answer silently

• n_free_parameters — the cluster space size. A strongly unstable cell with four gave imaginary modes reappearing at higher temperature (not physics); eleven did not. Fewer than six warns. On well-behaved cases both cutoffs agree exactly, so a small cluster space is a risk, not a guaranteed error — the note says that rather than overclaiming.
• convergence_drift — how far the parameters were still moving over the last five iterations. This is a fixed-point iteration run for a fixed step count, so it does not report its own convergence.

The cutoff is checked against half the shortest supercell dimension up front rather than failing deep inside the fit. hiphive's stdout reporting is captured — a library should not print into the middle of somebody else's loop — and a test asserts it.

A CI job of its own

hiphive reaches numba through trainstation, and numba caps numpy < 2.5. Adding it to the existing extras would quietly downgrade numpy on the 3.12 leg — which exists precisely to test the newest numpy. The extra would be covered at the cost of no longer covering what that leg is for, so it gets its own job.

The tutorial says plainly that its cell prints a fallback in the rendered docs (the docs environment runs numpy 2.5) and that the table beside it is what the cell produces where hiphive is installed.

Verification

• 948 pass on py3.12 without hiphive; 846 on py3.10; the 9 self-consistent-phonon tests pass in an environment with hiphive and numpy 2.4.6.
• Contract-verified rate stays 165/165. All 16 notebooks execute. Docs build.

🤖 Generated with Claude Code

https://claude.ai/code/session_016wh5NzNE9Wn49nuUm7zg2a