2021-05-12 Do Topologies Need Masses? Meeting notes

Minimum requirements for atoms?

• IP: Is it totally necessary for atoms to know their mass and element?

• MT: We had talked about the “minimum” that we need to know about before. It differs between output formats – Some would only need mass, others would only need atom names/elements.

• (General) – Somehow we’ll need to guess mass from eg. a PDB file. What’s the “industry standard” for how to do that, and how do we implement that standard in our infrastructure?

  • RDKit can do this (and presumably also OpenEye)

• Will we know element for coarse grained particles?

• Should Elements be allowed to be strings for things like coarse grained particles? Or weird atoms/elements?

  • JW – What if a user ran TypedAtom(name='XYZ', mass=1.75). Do we need to know the element in this case?

  • MT – Some exporters really need to know the element

  • IP – In some cases (eg GROMACS), they have a table that specifies masses for all atom types. I don’t know whether there are cases/it’s possible to change the mass away from what the table says it should be.

  • LW – Could you modify a file to make the change?

  • (General) – GROMACS in particular will sometimes “compress” parameters and other information into lookup files, but there are “uncompressed” versions of each that can be accessed/modified before a simulation.

  • LW + IP – Gromacs needs atom names, not necessarily elements.

  • MT – At some point, GROMACS input files do write atomic numbers, but I don’t know to what extent that’s used.

  • LW – GMX may give CG beads a atomic number of 0.

• Decision: We’ll store atomic_number as Optional[int]. We’ll see how normal user workflows look and decide whether something like atom_name should become part of the model.

  • Two questions to resolve:

    • How do we handle the fact that element and mass are sometimes redundant?

    • Should elements be members of an element package, or an atomic number?

  • MT – I don’t think that element and mass are always redundant. Question to ask ISN’T “which states are allowed” but instead “what are the ambiguous states we could reach in a normal workflow”?

    •  

• Decision: Mass will be required, but can be set to None in cases where the user intent isn’t known. Then an exporter will raise an error if someone tries to write out a system with a mass of None.

molecule.from_X_file(atom_names='atom_type')

• MT – What’s the plan with virtual sites?

  • JW – VSites from the openff toolkit will be part of the topology, and they’ll be inspect-able. VSites from NON-openFF sources are unknown right now.

  • IP – There are placeholder classes for TypedVSites and TypedVParticles

  • MT – I don’t have a ton of thoughts about virtualsites right now.

    • For reference:

      • Amber virtual sites: p321: http://ambermd.org/doc12/Amber21.pdf

      • GROMACS virtual sites: bottom of https://manual.gromacs.org/current/reference-manual/functions/interaction-methods.html

      •  

    • Decision – We won’t make a spec for vsites right now. TypedVirtualSite will allow for arbitrary attributes to be set, which people can use as they need. In the future, we’ll decide on how to standardize these in a way that interoperates between OpenMM, AMBER, GROMACS, and others.

    • We’ll worry about EXPORTING from smirnoff first, and converting from eg. AMBER to GROMACS much later.

    •  

•