Add quasi-harmonic phonon calculation to matcalc

[rul048]

The harmonic Hamiltonian of an ideal system is independent of volume, leading to a zero volume expansion coefficient. In order to accurately describe lattice expansion, it is necessary to incorporate anharmonic effects. The quasi-harmonic approximation (QHA) extends beyond the harmonic model by accounting for the variation of phonon frequencies with changes in the equilibrium volume induced by temperature. QHA provides a reasonable approximation over a broad temperature range below the melting point, balancing computational efficiency with accuracy when compared to fully anharmonic methods.

In quasi-harmonic phonon calculation, it is of the most importance to compute the phonon properties of specific material for slightly expanded and reduced volumes and find the equilibrium volume at the given temperature by minimizing the equation below with respect to volume at each temperature.

$$G(T, p) = U_{el}(V) + F_{ph}(V, T)$$

where $U_{el}(V)$ and $F_{ph}(V, T)$ are the electronic internal energy and phonon Helmholtz free energy under a specific volume, respectively.

However, first-principles harmonic phonon calculations have been already very expensive, not to mention that for QHA, these calculations are required to perform for multiple volumes.

Thanks to the advent and development of universal machine interatomic potentials (uMLIPs), it becomes possible to efficiently calculate materials properties with near-ab initio accuracy from potential energy surface. The code developed here achieves the first open-source application of uMLIPs in quasi-harmonic phonon calculations, allowing users to efficiently compute temperature-dependent thermodynamic properties, including but not limited to thermal expansion coefficient, Gibbs free energy, Grüneisen parameter, bulk modulus and heat capacity at constant pressure with one line.

Summary

Major changes:

• feature 1: ...
• fix 1: ...

Todos

If this is work in progress, what else needs to be done?

• feature 2: ...
• fix 2:

Checklist

• Google format doc strings added. Check with ruff.
• Type annotations included. Check with mypy.
• Tests added for new features/fixes.
• If applicable, new classes/functions/modules have duecredit @due.dcite decorators to reference relevant papers by DOI (example)

Tip: Install pre-commit hooks to auto-check types and linting before every commit:

pip install -U pre-commit
pre-commit install

[kenko911]

I think we should reformulate the PhononCalc in a way that includes Harmonic, Quasi-Harmonic and an-Harmonic approximations under one class by implementing methods for these three approximations.

[rul048]

Thanks for your comment. While the idea of integrating harmonic, quasiharmonic, and anharmonic methods under a single PhononCalc class might seem efficient at first, it could risk adding unnecessary complexity, increasing the likelihood of bugs and making it harder to debug and extend the code, as each of these methods relies on distinct underlying physics and requires different treatments in terms of numerical techniques, data structures, and computational workflows. For example, it might need to include a lot of conditional logic to manage the different methods. This could introduce unnecessary overhead, making the code less efficient. It might actually be more beneficial to maintain clear separation in terms of clarity, maintainability, performance, and ease of use.

From a user’s perspective, having separate and clearly distinct modules for each method might be more intuitive. It can reduce the learning curve since users won’t need to understand how all three methods are integrated within one class, but rather focus on the one relevant to their work.

From a developer’s perspective, the term "phonon" usually represents harmonic phonon calculations in many workflow packages. As we are the first groups to produce workflows going beyond this approximation, it's crucial to highlight it and make the users notice it at first glance.

[shyuep]

I would say we should implement different methods in different classes first if the logic is sufficiently different. Once we are happy with them, nothing is preventing us from writing a master "PhononAllProp" class that calls the rest of the methods to compute everything. We should only integrate if there are duplication in code and/or if computing of all approximations can be done more efficiently as an integrated system.

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 88 lines in your changes missing coverage. Please review.

Project coverage is 77.02%. Comparing base (e0b851f) to head (58cf5de).

Files with missing lines	Patch %	Lines
matcalc/qha.py	0.00%	88 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##              main      #30       +/-   ##
============================================
- Coverage   100.00%   77.02%   -22.98%     
============================================
  Files            8        9        +1     
  Lines          295      383       +88     
============================================
  Hits           295      295               
- Misses           0       88       +88     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[rul048]

Oh, I see it is actually not the issue of ruff, it seems that the mypy was skipped before so the error information was refleted in the ruff. Learn something new today. The error is because I used the new static calculation feature in this pr, which has not been merged already. It should work after I finished all the unittests and merged them.

[shyuep]

Again, need unittest for this new functionality.