search

mosdef-hub / gmso

Flexible storage of chemical topology for molecular simulation
https://gmso.mosdef.org
MIT License
52 stars 33 forks source link

Support pair potential matrix parameters #313

Closed joaander closed 2 years ago

joaander commented 4 years ago

For example, a typical pair potential for bead spring polymers is:

A-A: epsilon=1.0, sigma=1.0, r_cut=2.5
A-B: epsilon=1.0, sigma=1.0, r_cut=2**(1/6)
B-B: epsilon=1.0, sigma=1.0, r_cut=2.5

I realize that this example only varies r_cut along the matrix which is possibly out of scope for GMSO. There are other cases where the potential parameters themselves will vary.

uppittu11 commented 4 years ago

Should we add a PairType object, which is similar to the BondType, but applies to non-bonded pair potentials? That way you can define custom unique pair potentials (like my tabulated CG non-bonded for example).

mattwthompson commented 4 years ago

Parashara and I talked about this at length and we eventually agreed there should be a new class that defines cross-interactions. The current AtomType class is implicitly self-self, and it would be useful to have another class, that also subclasses out of Potential that more clearly represents a cross-interaction. There could be some utility functions that take in objects atom_type_i and atom_type_j and produces cross_interaction_ij, but this would not necessarily be the intended constructor.

@zijiewu3 needs this so he will be working on it. @shivrajkotkar and @jingxiangguo will also find this useful so it would be worth working on it together

I think it is also useful to consider a way to either have this behavior as a thin wrapper around existing objects or finagle the existing AtomType class to point to different objects. But there are downsides to those that prevent me from advocating for them - mostly that pointers/wrappers don't as explicitly store this data in memory.

b-butler commented 4 years ago

I think it makes sense for a PairType, and in this case move all the potential parameters to it and don't store potential parameters in AtomType. The two could interface using the AtomType to inform choice of potential parameters. It seems to be a bifurcation of the same concept into two classes to have self interactions in AtomType and mixture interactions in another class.

daico007 commented 2 years ago

Basic support via https://github.com/mosdef-hub/gmso/pull/484