Repository navigation
[WIP] CALPHAD workflow with ATAT sqs2tdb - #1574
hrushikesh-s wants to merge 28 commits into
Conversation
Co-authored-by: Zekun Chen <27995442+ZKC19940412@users.noreply.github.com> Co-authored-by: SonoKunal <77825175+SonoKunal@users.noreply.github.com> Co-authored-by: sunflowen <45136689+sunflowen@users.noreply.github.com> Co-authored-by: YixinZhang233 <298216219+YixinZhang233@users.noreply.github.com>
hrushikesh-s
changed the title
…ll, allow 2000 relaxation steps
|
Btw, Do you know https://github.com/ICAMS/calphy ? |
|
Hi Janine. Thanks for sharing info about calphy. Based on my preliminary understanding, it seems that calphy gets full free energies from thermodynamic integration in LAMMPS, and this PR follows the ATAT sqs2tdb approach, which takes the pure elements from SGTE and fits only the mixing terms to force field energies, so it is much cheaper and works with any force field in atomate2. Maybe I can add support for calphy based phase diagram as well in another PR? What do you think? |
…nto calphad # Conflicts: # .github/workflows/testing.yml
Yes, it is a different approach indeed. I was just wondering if you are aware of this approach. And, yes, if you are interested in implementing this, I am happy to accept a PR |
Sounds good.. @ZKC19940412 and I will create a new PR for calphy, and maybe also compare it with the results of this current PR... Might be a good idea to see how much they differ in their final phase diagrams for binaries. |
…iquid temperature
…axations and MACE-OMAT-0
|
The PR is in good shape. The atomate2 workflow with mace-omat-medium reproduces the phase diagram about as well as native PhaseForge. One suggestion: the liquid-phase MD sampling needs tens of short MD runs to converge. We should either benchmark how the number of runs affects the liquid-phase region of the phase diagram, or add a way to decide how many runs are needed automatically. For the second option, PhaseForge has something we could consider implementing: In src/ternary_search.cpp (https://github.com/dogusariturk/PhaseForge/blob/main/src/ternary_search.cpp), they run a ternary search over the POSCAR lattice scaling factor to find the equilibrium volume. Each iteration evaluates the energy (one MD run) at two interior points of the bracket, keeps the side containing the minimum, and shrinks the bracket to 2/3 of its width until it is smaller than eps. With the default bracket of 0.7 to 1.3 and eps of 0.01, that is around 20 MD runs with a deterministic stopping rule, instead of a fixed dense grid of volumes. One caveat: their search is adaptive sampling over volume, assuming energy vs volume is unimodal in the bracket. It cuts down runs spent scanning the volume axis, but it is not a convergence criterion for the statistical averaging of the liquid itself. So it is the adaptive-search idea we would borrow, not a drop-in solution. If our bottleneck is independent runs at the same state point, we would still need a separate stopping rule, for example based on the standard error of the averaged quantity. |
…e CALPHAD tutorial
…with the extra lattices of PhaseForge
|
Thanks! I ran each 864-atom liquid SQS ten times for 20 ps, plus once for 100 ps, for Ni-Re, Co-Ni and Cr-V with all four potentials. One 20 ps run gives the liquid L0 to within 0.4 to 1.2 kJ/mol and the liquidus maximum or minimum to within 11 to 25 K, the mean of several runs scatters less roughly with one over the square root of their number, and the 100 ps runs show no drift, so the error is statistical. A volume search is not needed here, since the liquid MD runs NPT at zero pressure and finds its volume in the same run. For the stopping rule, the workflow now stores the standard error of each liquid energy from five blocks of the run, and it gives the scatter between runs to within about 30%, so a single run already shows whether more are needed. Should I keep one run per SQS as the default and point users to energy_standard_error for deciding when to average more runs, as the tutorial now does? or is there something else that you suggest to do instead? |
The entropy is phonopy's sum over a q-point mesh at 3000 K, from the supercell, displacement and force jobs of the phonon workflow. Lattices with too many imaginary modes are fitted to the energies only. The tutorial is updated with the new diagrams.
|
Nice benchmark, and I agree the error is statistical. I think MD protocol and the error metrics as shown in the tutorial works. Once you had the vibrational entropy and short range order as options whenever the users want, I think it is close to complete shape. |
…ange order option Frequencies below 0.05 THz are left out of the phonopy entropy sum, so the result no longer depends on the sign of the noise at Gamma. short_range_order passes -sro to sqs2tdb -fit.
@ZKC19940412, the vibrational entropy is now in the workflow. I have also added short_range_order, which passes the -sro option to the sqs2tdb fit and adds its CVM correction from the same SQS energies. |
|
Also the current workflow is one to one interchangeable to VASP, with small change in the parameters in case vasp MD for liquid phase gets expensive. |
@JaGeo, since version 2.1.0 calphy is under the Academic Software Licence, which allows only non-commercial academic use. Would it be fine to add a calphy workflow with calphy as an optional dependency that users install themselves? The force fields would run through LAMMPS, either MACE with ML-IAP or any ASE calculator with Rootstock, which already works with calphy (calphy#256). This would also help #1560, since the free energy and phase transition analysis in Section 5 of its tutorial could then be done with calphy. or is there something else that you suggest to do instead? |
|
Sounds good. I will continue tomorrow. |
# Conflicts: # .github/workflows/testing.yml
|
Leave notes on liquid phase MD for next stage development: Since each MD run is independent, it is much efficient to run the MD with either ALCHEMI(https://developer.nvidia.com/cuda/cuda-x-libraries/alchemi) or batch MD runs using torchsim, which some codes from the torchsim tutorial might be useful: https://github.com/materialsproject/atomate2/blob/main/tutorials/torchsim_tutorial.ipynb |
|
When continuing to test this workflow, I constantly encountered the warning from src/atomate2/common/jobs/calphad.py line L552-556, and I think it requires more prints out to be useful to the user. First, 0.1 in what unit? 0.1 eV/A^3, 0.1 Gpa, or 10% of change (dimensionless)? Also what algorithm of optimization is used and how many steps, and whether cell is optimized spontaneously. Those should be printed when the warning is raised. |
|
Also I am almost certain now our workflow at current form handles mostly on phase diagram on ambient and zero-stress condition, while calpahd calculations are often used to explore phase diagram at high pressure. If our workflow temporarily is less flexible to such systems, we should add the one more line to known limitation to the notebook, and forcefield.md that "The workflow targets ambient pressure; all relaxations and liquid MD run at zero pressure, and extension to high-pressure phase diagrams requires further testing". |
|
@ZKC19940412, the old warning is now two, one for a relaxation that did not converge and one for a relaxation_strain above 0.1. The strain warning gives the value and says it is dimensionless and leaves out the change of volume, as in ATAT checkrelax, and both warnings print the relaxation settings, which are FIRE, fmax = 0.01 eV/Å, at most 1000 steps and a relaxing cell by default. The notebook and forcefields.md now state that the cells and the liquid come from zero pressure and that the SGTE data are for 1 bar, so the TDB file does not cover high pressure. Batching the liquid MD with torchsim or ALCHEMI is now in the TODO. Does that look fine? |
|
Wonderful, I think torchsim or ALCHEMI integration worths a separate PR (feature enhancements). After this accurate and basic PR on phase diagram gets merged. |
# Conflicts: # .github/workflows/testing.yml
Summary
Include a summary of major changes in bullet points:
sqs2tdbtool of ATAT (van de Walle et al., Calphad 58, 70, 2017).sqs2tdbthen fits each lattice and writes one TDB file, which pycalphad can read.short_range_order=Trueadds ATAT's approximation of the short range order.sqs2tdbwould carry on silently, for example for a missing energy or an empty parameter. It warns for relaxations that did not converge or distort strongly. The relaxation strain, the fraction of imaginary modes and the MD statistics are stored for each structure. A lattice with too many imaginary modes is fitted to the energies only.PhononBSDOSDocsince Breaking: Use phonopy's sum over the q-point mesh for the phonon thermal properties #1576.CalphadMakerfor force fields and aSQS2TDB_CMDsetting. Docs in forcefields.md.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.
No new Python dependencies. ATAT is not on PyPI, and its license does not allow us to ship a copy. CI downloads the official ATAT tarball, checks its sha256 and builds the three programs that
sqs2tdbneeds, in about 15 s.The tutorial needs pycalphad to draw the diagrams. The notebook CI job installs it.
TODO (if any)
If this is a work-in-progress, write something about what else needs to be done.
EquilibriumVolumeMakerfinds the same volume from a pressure-volume fit over several NVT runs. I can switch to it if you prefer.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.