Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Discussion]: Duplication / overlap of efforts with atomate2 #39

Open
1 task done
esoteric-ephemera opened this issue Oct 17, 2024 · 3 comments
Open
1 task done

Comments

@esoteric-ephemera
Copy link

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

  • I agree to follow this project's Code of Conduct
@shyuep
Copy link
Contributor

shyuep commented Oct 17, 2024

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.

@utf
Copy link

utf commented Oct 17, 2024

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).

@shyuep
Copy link
Contributor

shyuep commented Oct 17, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants