You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
HOOMD writer in GMSO is incompatible with forcefields that parameterize connections by a mix of types and classes.
Bug Report:
The majority of the forcefields we have in the ecosystem define the connection types by a set of classes that makes up their components. However, we technically do support defining the connection by types as well, to give users flexibility to define a dihedral specifically while generally defining other connections by their classes (see this PR discussion for more details). This can cause confusion when identifying unique sets of connection_types by a string that makes up the 4 members; there needs to be some flexibility to write by either atomtype or atomclass.
This issue will need to be tested by adding a forcefield that behaves this way. Something such as
I think we also need some more specificity of how to define a forcefield i.e., is it acceptable to write an bondtype as:
BondType = class1, type2
I believe the plan will be to address this in the coming months
TLDR; to_hoomd_snapshot and to_hoomd_forces will not work if your topology is defined in such a way as to be have both type and class definitions for connections.
The text was updated successfully, but these errors were encountered:
HOOMD writer in GMSO is incompatible with forcefields that parameterize connections by a mix of types and classes.
Bug Report:
The majority of the forcefields we have in the ecosystem define the connection types by a set of classes that makes up their components. However, we technically do support defining the connection by types as well, to give users flexibility to define a dihedral specifically while generally defining other connections by their classes (see this PR discussion for more details). This can cause confusion when identifying unique sets of connection_types by a string that makes up the 4 members; there needs to be some flexibility to write by either atomtype or atomclass.
This issue will need to be tested by adding a forcefield that behaves this way. Something such as
I think we also need some more specificity of how to define a forcefield i.e., is it acceptable to write an bondtype as:
BondType = class1, type2
I believe the plan will be to address this in the coming months
TLDR;
to_hoomd_snapshot
andto_hoomd_forces
will not work if your topology is defined in such a way as to be have both type and class definitions for connections.The text was updated successfully, but these errors were encountered: