You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some of the workflows / tasks defined in matcalc and atomate2 for ML interatomic potentials are nearly identical. Part of this is because the initial implementation of the relaxation forcefield class was based on matcalc / matgl. However, our efforts diverged after that, but led to similarly structured workflows (forcefield-agnostic requiring only a common implementation of a calculator-like object).
In particular, I see overlap with relaxation, EOS, and quasi-/harmonic phonon flows. atomate2 has a few extra jobs/workflows (MD, Grüneiesen) and will eventually support NEB as matcalc currently does.
Obviously the intended purposes of the two codes are different: atomate2 is meant for modular high-throughput atomistic workflows, and matcalc is more for lower-throughput calculation of specific properties with ML forcefields.
Still, I think it's good to make sure we're not duplicating effort between projects where there's no need to (e.g., workflow schemas / data schemas). Copying @shyuep and @utf in case you have thoughts on this
Proposed Solution
Further discussion between the two teams
Alternatives
No response
Code of Conduct
I agree to follow this project's Code of Conduct
The text was updated successfully, but these errors were encountered:
I think this is somewhat similar to the VASP input sets problem - there is the actual logic for computing a property (e.g., phonons, EOS, elastic constants) and those should be in matcalc. And there is the workflow stuff, which is in atomate2. Atomate2 can just use matcalc as a dependency and call the appropriate property calculators to get the properties. I should add that matcalc has far more properties than atomate2 at the moment and more will be added.
I'd be very open to this if it can be done cleanly. Having only skimmed the source for matcalc I'm not clear how that would actually work in practice. If you have any suggestions @esoteric-ephemera I'd be open to that.
I might have missed something but from what I can tell atomate2 has basically the same number of properties as matcalc (the NEB workflow isn't merged yet but we also have anharmonic phonons, klatt etc).
As far as I know, atomate takes an input structure, perform a calculation and then returns the result. That is precisely what matcalc does. Also, almost all those properties were on matcalc since the 0.0.4 release on Jan 1 2024. Only a few things have been added since.
Email (Optional)
No response
Problem
Some of the workflows / tasks defined in matcalc and atomate2 for ML interatomic potentials are nearly identical. Part of this is because the initial implementation of the relaxation forcefield class was based on matcalc / matgl. However, our efforts diverged after that, but led to similarly structured workflows (forcefield-agnostic requiring only a common implementation of a calculator-like object).
In particular, I see overlap with relaxation, EOS, and quasi-/harmonic phonon flows. atomate2 has a few extra jobs/workflows (MD, Grüneiesen) and will eventually support NEB as matcalc currently does.
Obviously the intended purposes of the two codes are different: atomate2 is meant for modular high-throughput atomistic workflows, and matcalc is more for lower-throughput calculation of specific properties with ML forcefields.
Still, I think it's good to make sure we're not duplicating effort between projects where there's no need to (e.g., workflow schemas / data schemas). Copying @shyuep and @utf in case you have thoughts on this
Proposed Solution
Further discussion between the two teams
Alternatives
No response
Code of Conduct
The text was updated successfully, but these errors were encountered: