GMSO: Flexible storage of chemical topology for molecular simulation

GMSO is a flexible storage of chemical topology for molecular simulation. With a few lines of GMSO code, together with mBuild and foyer, users can rapidly prototype arbitrary parameterized chemical systems and generate data files for a wide variety of simulation engines.

GMSO is a part of the MoSDeF ecosystem

GMSO is designed to be a general and flexible representation of chemical topolgies for molecular simulation. With an emphasis on assuming as little as possible about the chemical system, model, or engine, GMSO can enable support for a variety of systems. GMSO is a part of the MoSDeF (Molecular Simulation and Design Framework) ecosystem, and is intended to be a generalized alternative for the foyer package. Libraries in the MoSDeF ecosystem are designed to provide utilities neccessary to streamline a researcher’s simulation workflow. When setting up simulation studies, we also recommend users to follow the TRUE (Transparent, Reproducible, Usable-by-others, and Extensible) standard, which is a set of common practices meant to improve the reproducibility of computational simulation research.

Goals and Features

GMSO’s goal is to provide a flexible backend framework to store topological information of a chemical system in a reproducible fashion. Topology in this case is defined as the information needed to initialize a molecular simulation. Depending on the type of simulation performed, this ranges from:

  • particle positions

  • particle connectivity

  • box information

  • forcefield data

    • functional forms defined as sympy expressions

    • parameters with defined units

    • partial charges

    • tabulated data

    • etc.

  • Other optional data

    • particle mass

    • elemental data

    • etc.

With these driving goals for GMSO, the following features are enabled:

  1. Supporting a variety of models: in the molecular simulation/computational chemistry community: No assumptions are made about an interaction site representing an atom or bead, instead these can be atomistic, united-atom/coarse-grained, polarizable, and other models!

  2. Greater flexibility for exotic potentials: The AtomType (and analogue classes for intramolecular interactions) uses sympy to store any potential that can be represented by a mathematical expression.

  3. Adaptable for new engines: by not being designed for compatibility with any particular molecular simulation engine or ecosystem, it becomes more tractable for developers in the community to add glue for engines that are not currently supported.

  4. Compatibility with existing community tools: No single molecular simulation tool will ever be a silver bullet, so GMSO includes functions to convert between various file formats and libraries. These can be used in their own right to convert between objects in-memory and also to support conversion to file formats not natively supported at any given time. Currently supported conversions include:

    • ParmEd

    • OpenMM

    • mBuild

    • more in the future!

  5. Native support for reading and writing many common file formats:

    • XYZ

    • GRO

    • TOP


    • GSD

    • indirect support, through other libraries, for many more!