Open anabiman opened 3 years ago
Yes, that sounds like an excellent way to build in some interoperability with other codes and (CG) techniques! Keep me in the loop 👍
Great, will do! I will start working on the repository sometime next week and will add you as a collaborator. I will keep this issue open until then.
The purpose of this issue is to suggest building a "component" for auto_martini (dubbed
mmic_ffpa_autom
) that makes it part of the MMIC ecosystem MolSSI is currently developing. The idea is to designmmic_ffpa_autom
as a wrapper aroundauto_martini
to provide force field assignment capabilities in a way that makes it interoperable with other codes, which grantsmmic_ffpa_autom
numerous benefits. The diagram below sums how this component would work in practice and its dependence onauto_martini
.The "AssignInput" and "AssignOutput" are just data models (e.g. python dictionaries) that represent a general schema specification that many other similar components adhere to. Using this component is trivial, as is the case with all components in MMIC:
With this design,
mmic_ffpa_autom
will:mmic_cg
),mmic_ffpa_autom
could be now used with other coarse-graining technique that become available inmmic_cg
. Note thatmmic_cg
will by default support bead-based CGs.mmic_ffpa_autom
will benefit from those additional capabilities without any changes required to its source code.mmic_ffpa
is a general force field assignment component designed to cover a wide spectrum of domains in the computational molecular sciences, based on the MMSchema specification. Under the hood,mmic_ffpa
uses specialized components such asmmic_ffpa_autom
. This has the potential of increasing the user base of auto_martini beyond the CG community.Note: no changes to the
auto_martini
source code are required, sincemmic_ffpa_autom
andauto_martini
would be separate packages.Is this of interest to you @tbereau ? If so, I'll add you as a collaborator so you can help me tackle issues pertaining to auto_martini that might arise in the future.