Discussion on long term changes for GMSO-MoSDeF workflows

[CalCraven]

During the development meeting of 22-06-30, a few points were brought up by various contributors that are relevant for the next steps of a GMSO centered workflow.

Overview of discussion

---

GMSO is designed to handle flexible and complicated systems. It does that by leveraging the power of Foyer's SMARTS grammar matching. It also leverages (SymPy)[https://docs.sympy.org/latest/index.html] and Pydantic libraries to make these flexible and controllable classes with a default set of testable attributes, instead of hard coding in floats and lists for parameterized information. Because this flexibility has been the focus of the development team and handling the complexity that such a flexible workflow should entail, getting new user feedback and integration into workflows has been neglected. This brings up two points that the future development of GMSO should focus on.

Development Focus 1:

---

Two sets of documented tutorials are going to be needed.

1. One should be focused on getting new users. This would show off the basics, like how to manipulate and interrogate a GMSO topology, how to use the supported readers and writers (and information on contributing to this writers), and where GMSO fits into the atomtyping workflow.
2. The second should focus on encouraging contributors. This should be more code level based information about subclassing of Pydantic BaseModels, creating new functional forms for custom potentials not inherently supported, GMSO forcefield development and storage, and detailed explanation of the atomtyping steps with information about how to use abstract grammars in a forcefield.

These tutorials should encourage a more cooperative community and accelerate the finding of bugs and handling of new cases.

Development Focus 2:

---

This focus should be on encouraging bio-field users to try MoSDeF. Recent contributions of residue support have been a step in the correct direction. However, while GMSO has focused on more complex parameterization, some focus should be given to simpler workflows. Most notable are examples where a single biomolecule has already been parameterized in a .psf or .top file, and the parameterization is done. Following similar workflows that use tools such as Avogadro, MolView, Hypercube, and other 3D structure softwares. These workflows allow users to skip the SMARTS string development necessary to create GMSO forcefield XMLS and identify atomtypes, since that work has already been over the many years that bio forcefielding has been developed. What is needed is a way to build up complicated bio-molecules using mBuild geometrical transformations while keeping track of the parameters in a "Molecule Template" that is read into GMSO, and mapped onto the final, extended structure. This would be extremely useful for groups that want to leverage GMSO writers without getting into the weeds of creating SMARTS strings for each atomtype in the system.

Note This could also be addressed with a utility in GMSO that could take a parameterized structure, and write out a forcefield with the minimal set of SMARTS that would define a generic forcefield. This utility would leverage the BondGraph to generate these SMARTS strings, but could be tougher with increased complexity of the molecules.