Question: What is the relationship between foyer and gmso?

[bkpgh]

"GMSO is a part of the MoSDeF (Molecular Simulation and Design Framework) ecosystem, and is intended to be the backend replacement for the foyer package."

What exactly does "backend replacement for the foyer package" mean? What is the relationship between foyer and gmso? What capabilities that foyer currently performs are anticipated to be subsumed by gmso?

[umesh-timalsina]

We are currently using parmed to store the parameterized system after atom typing with foyer. The Forcefield class for foyer is subclassed out of OpenMM. While both tools work great, gmso intends to replace them. Here is the current progress on that front:

1. GMSO for foyer: https://github.com/mosdef-hub/foyer/pull/358, which depends on #438, Our goal is to roll this out very soon.

With this rolled out, we plan to host a virtual demo hour showcasing some of our existing workflows. Please join our gitter for further updates.

[bkpgh]

Thanks very much. "very soon" means days? weeks? months? I was about to attempt some foyer modifications and would wait if major changes were about to be implemented.

[umesh-timalsina]

It should take us couple of weeks for these changes to be rolled out. What modifications are you trying to make and are there any specific issues that you have run into that you wanted to fix?

[EqualAPriori]

I had a question about this as well -- does the integration mean that Foyer will no longer be needed (i.e. GMSO supplants Foyer)? Do they use the same or different xml formats?

Does Foyer support custom-defined potential types?

[daico007]

GMSO supposed to be our backend data structure, i.e., it is intended to store information regarding the chemical topology (positions, atom types, connection types, etc.,). Foyer is intended to be a atomtyper, i.e., use graph-matching to identify atomtype of atom in a structure. Before GMSO was developed, foyer was using parmed and OpenMM as backend, hence, we have the foyer XML (an extension from OpenMM XML). At the moment, we are working to integrate GMSO to be the default backend of foyer in place of parmed and openmm. Both package will still exist after the integration, though foyer may have some change to make it more agnostic and work with more type of input structure. We will also start to convert and use GMSO XML format for both libraries.

[EqualAPriori]

I see! I have a bespoke simulation code and I'm trying to figure out which tool I should be using to "store" my system, GMSO or Foyer. I do have some non-standard potentials that aren't part of the default OpenMM potentials (although still definable using custom forces in OpenMM) -- does this mean I should be using GMSO? Does GMSO also support SMARTS strings definition of potentials?

Also, my understanding of the internal OpenMM force field is that it stores, e.g. each atom as an independent object that needs to be parameterized separately (e.g. addParticle() in NonbondedForce), i.e. OpenMM does not natively atom type. Does GMSO also operate the same way? Or does it store two levels of description: a potential-level description defined by atom types, and then also the atom-by-atom definition like OpenMM?

[daico007]

Yeah, I think GMSO Topology can be used to store those information, but we are still working on finalizing the design of the data structure, focusing on effectively storing hierarchical information and increase its performance. In GMSO, each atoms/bonds will have a pointer to its atomtypes/bondtypes object, which are stored in an ordered set at the top (Topology) level. If I remember correctly, we still have SMARTS string definition in GMSO XML and AtomType object.

[EqualAPriori]

Oh cool! I just saw that AtomType stores SMARTS.

I was looking through the documentation, and it wasn't clear how to create ForceField objects manually w/out using xml files. Do I just instantiate potentials and do direct dictionary assignment to the appropriate potential_types dictionaries of an instance of ForceField()? Also, the documentation does not mention that FF stores pairpotential_types(), although there is a field for it in the code.

Some other questions:

• why does AtomTypes store expression_potential (and potential)? what if I have multiple potentials (that use mixing rules) that use the same atom types? One instance is if I have beads interacting by both LJ and Gaussian potentials superimposed (e.g. this paper). I guess I'm a bit confused by what an "AtomType" potential means.
• if I have a potential with the same parameters applying to (A,B), (A,C), and (B,C) interactions, is it possible to define a single potential that applies to all three pairings? Or would I need to define a new potential for every atom type pairing? One application of this kind of scenario is if I have a correction to the electrostatic interaction that applies to all species, and requires knowledge of atom-type-specific properties (say a characteristic charge radius) and the atom-type's charge. Would defining the pair potential once suffice (and, e.g. store the parameters in an atom type)? Or do I have to repeat the definition, and include parameters as part of each individual pair_potential?

Let me know if this is starting to be a digression and should be a new issue.

Thanks for all the help!

[bkpgh]

If GMSO is storing SMARTS, does that mean the authors' are planning on enabling atom-typing based on SMARTS?

On 3/8/22 14:24, Kevin wrote:

Oh cool! I just saw that AtomType stores SMARTS.

I was looking through the documentation, and it wasn't clear how to create ForceField objects manually w/out using xml files. Do I just instantiate potentials and do direct dictionary assignment to the appropriate |potential_types| dictionaries of an instance of ForceField()? Also, the documentation does not mention that FF stores |pairpotential_types()|, although there is a field for it in the code.

Some other questions:

• why does AtomTypes store |expression_potential| (and |potential|)? what if I have multiple potentials (that use mixing rules) that use the same atom types? One instance is if I have beads interacting by both LJ and Gaussian potentials superimposed (e.g. this paper https://aip.scitation.org/doi/full/10.1063/1.2431169). I guess I'm a bit confused by what an "AtomType" potential means.
• if I have a potential with the same parameters applying to (A,B), (A,C), and (B,C) interactions, is it possible to define a single potential that applies to all three pairings? Or would I need to define a new potential for every atom type pairing? One application of this kind of scenario is if I have a correction to the electrostatic interaction that applies to all species, and requires knowledge of atom-type-specific properties (say a characteristic charge radius) and the atom-type's charge. Would defining the pair potential once suffice (and, e.g. store the parameters in an atom type)? Or do I have to repeat the definition, and include parameters as part of each individual pair_potential?

Let me know if this is starting to be a digression and should be a new issue.

Thanks for all the help!

— Reply to this email directly, view it on GitHub https://github.com/mosdef-hub/gmso/issues/496#issuecomment-1062122594, or unsubscribe https://github.com/notifications/unsubscribe-auth/ANPR6FLZTMR4J645A5JXEGTU66SOXANCNFSM4WSJXPPQ. You are receiving this because you authored the thread.Message ID: @.***>

[umesh-timalsina]

why does AtomTypes store expression_potential (and potential)? what if I have multiple potentials (that use mixing rules) that use the same atom types? One instance is if I have beads interacting by both LJ and Gaussian potentials superimposed (e.g. this paper). I guess I'm a bit confused by what an "AtomType" potential means.

There are two ways to instantiate an AtomType with a functional form and parameters:

1. You can supply a gmso.utils.expression._PotentialExpression instance to its constructor
2. You can either supply expression and parameters separately to its constructor

If you choose the second option, an instance for _PotentialExpression is created in the constructor itself to manage the functional form. Once done, atom_type.expression and atom_type.parameters are exposed as properties of the class:

https://github.com/mosdef-hub/gmso/blob/13ef01d47f51a7e309548c574508332edc3ff483/gmso/abc/abstract_potential.py#L74-L77

https://github.com/mosdef-hub/gmso/blob/13ef01d47f51a7e309548c574508332edc3ff483/gmso/core/parametric_potential.py#L104-L107

[umesh-timalsina]

If GMSO is storing SMARTS, does that mean the authors' are planning on enabling atom-typing based on SMARTS?

This is possible with foyer.general_forcefield. But please keep in mind that we are in early stages of development and a lot can change with the underlying implementation, but we hope to keep the API consistent.

[daico007]

Modified has been proposed and implemented in the develop branch, GMSO will be main object user interact with to perform parameterization, while foyer will become the backend that only perform the atomtyping step (provide a typemap for GMSO to carry the parameterization step)