Open ocmadin opened 4 years ago
jchodera
commented
4 years ago There is no way for an OpenMM Topology object to encode the chirality of the molecule since it only include connectivity and elements. This isn't a bug, but rather a limitation of the OpenMM Topology object.
Can you use a different way to get your system into the parameterization pipeline? How did you generate your simulation box? Do you have coordinates too?
jchodera
commented
4 years ago One idea: We could allow the user to specify an optional map of residue names to molecules that could be used to force assignment of molecules to any specified residues in the topology? This is an abuse of OpenMM's Topology format, but may be a convenient one.
ocmadin
commented
4 years ago This is part of mixture benchmark set that we're running via evaluator, so we'd have to make changes to evaluator system generation pipeline to avoid this. Since it's just a benchmark set, we'll probably just omit these molecules for now, and circle back to to it later.
jchodera
commented
4 years ago Since the evaluator uses an object model that cannot represent a mixture of enantiomers, you will absolutely need to make changes to the evaluator system generation pipeline if you ever want to represent systems containing more than one enantiomer of the same compound correctly.
My question for you and @SimonBoothroyd is "what would be the most convenient way for you to augment your representation to indicate chirality?" Is it via an alternative object representation, or would the simple suggestion above (of forcing assignment to specific molecules) be an easier path?
SimonBoothroyd
commented
4 years ago Since the evaluator uses an object model that cannot represent a mixture of enantiomers
Currently we do carry along the stereochemistry of the components in the system (as well as the relative amounts of the different enantiomers), however at some point we need to go from a list of OpenFF Molecule objects (created with stereochemical information) and a coordinate file to an OpenFF Topology and then onto a System object.
My preference would be for from_openmm to take an optional coordinates argument, from which the stereochemistry may be inferred.
davidlmobley
commented
4 years ago Seems like taking an optional coordinates argument would be a good solution to this problem. CC @j-wags and @trevorgokey
Describe the bug Parameterizing a mixture of enantiomers, with stereochemistry defined in their SMILES strings, raises a
DuplicateUniqueMoleculeErrorwhen creating a Topology object from an openmm topology.To Reproduce Steps to reproduce the behavior. A minimal reproducing set of python commands is ideal.
Output
Computing environment (please complete the following information): RHEL 7
Additional context Here's an image of the molecules: