MosDeF repos follow Semantic Versioning for their releases. All releases are tagged in GitHub. For example- mBuild version is 1.10.8. Creating a new release Use bump-my-version to manage releases: pip install bump-my-version After all the commits (wanted in this release) are merged to main, clean your repository source tree (no uncommited files and extra commits). Fetch upstream and merge to your main branch. $ git checkout main $ git fetch upstream

Features Native method to get parameters from a Forcefield object (#382) Decouple parmed from the foyer atomtyper (#389) Return a list of available Forcefield loaders based on currently installed plugins (#388) Maintenance Upload CodeCov reports without tokens (#393) Update user documentation (#376)

Foyer Handlers (PR #114) Few questions at this point: Should foyer directly operate in off's Topology for now? This can be achieved with some additions to foyer's run_atomtyping function IMO. Might open up manageable can of worms. Regarding the above comment, we have managed to decouple parmed from the atomtyping step. For atomtyping to work, you would need a generic Topology Graph that subclasses a networkx Graph. Would you guys be interested in providing a conversion from an OFF Topology to a foyer topology graph? UT -- Could also accept inputs like NetworkX. This is how things work under the hood, but there are no API points to handle NX graphs specifically. MT -- This sounds like a good idea. One thought would be to have Foyer have its primary functionality be on something like a networkX graph, and have some automatically-called converters that take whatever input it normally takes (mBuild, ParmEd, etc) and convert that to a networkX graph. UT -- Agree. We'll try to decouple internal representation from the variety of inputs it can use.

# Matching tokens

https://github.com/mosdef-hub/gmso/pull/492 Function select_params_on_networkx: Its not clear to be why we need so many if/else ladders. Having said that there should be a way to consolidate these ladders into one by employing the signature like select_params_on_networkx(networkx_graph, *atoms) It might be not be necessary to cast the networkx nodes to a list if you don’t want to reiterate through it. It already returns an iterator

MoSDeF looks like not an equal partner but a subordinate. The bigger question is what is our role in collaboration? It looks like our contribution should be less. What OpenFF is doing? Pushing to their code base -> Part of their contribution What we wanted to do?

SPICE DeviceModels

In this note we propose an interoperability module between gmso and the openff-system objects. The deliverables are the following: A conversion between a typed gmso Topology and an OpenFF System object and vice versa. Develop a plugin architecture that discovers this layer for both GMSO and OpenFF-System. openff.System object details: Inorder to create an openff.System Objects we need the following (see the following link): Potential Handlers: Potential handlers for a System object is a dictionary of all the Forcefield Paramters for the System Object. Topology: An openff.topology.topology.Topology object.

Foyer 0.7.7 Maintainence Entrypoints Conda (To ensure that we have our plugins supported) (#345) Update foyer docs link (#347) Add link to GitHub/homepage in docs footer (#351) Update copyright years in docs (#353) Use bump2version for versioning (#357) Fix typo in desc (#361) Remove travis (#366, #368)

Inductor A generic Inductor. Attributes: Name: L Description: Inductance Type: float Unit: H Default: 1

GMSO 0.3.0 Breaking Change Integrate Pydantic for gmso.abc abstract classes (#431) Features Improve GROMACS top writer (#306, #330, #423) Add method to get Site’s index (#343, #365) Add Improper Connection and ImproperType Potential (#338

In paper Peter attached, we have utilized the scikit-learn python library for the machine learning part and the rdkit cheminformatics python library for coming up with the descriptors of the system. Our goal was to develop a model that related the chemistry of the monolayer film with the measured properties. While RDKIT made a lot of sense for the problem, scikit learn was somewhat arbitrarily chosen because it happened to be convenient to use. Types of Analyses: Simulation Trajectories-> Use packages to calculate properties with whatever we want to. Which systems are worth simulating? Science Heavy? Pick our systems on what experimental data to compare to? Ray simulates 90% of the system based on experimental data. Parashara: Might do tuning coarse-grain models. signac could fit with ML/AI pipeline (Michigan) Two things that CO cares about: (One) Coeffiecient of friction

To specify a typed system specification we need the following containers (): The base container (System or Topology): A container object representing physical constructs as well as the necessary physics that define a molecular system. The non-physical interaction container (ForceField, PotentialCollection): A container representing non-physical constructs like eneriges, functional forms of interactions etc... in a typed/parameterized molecular system. We should be able to create a ForceField or a container of Potentials from a System or Topology container (if they exist). Topology or System As mentioned earlier, a Topology is a collection of physical constructs that define a molecular system. To define a Topology/System, the following list (non-exhaustive) of attributes and methods are neccessary: Topology/System

How to design a system specification, UML (Papayrus), GME Models with docuementation before the OPENFF meeting?? (Umesh will start the template and diagram, and all group members can chime in.) XML writers for GMSO objects need this issue to be sorted out (https://github.com/mosdef-hub/gmso/issues/464) (All of it has to be "class" Based (vs types)) Serialization Handler Ideas (https://github.com/mosdef-hub/gmso/pull/462) Brad's PR (https://github.com/mosdef-hub/mbuild/pull/784) Foyer's atomtyping in GMSO Additional Forcefield functions like (https://github.com/mosdef-hub/gmso/issues/465) XML Converters (https://github.com/mosdef-hub/gmso/pull/438) Release timeline for GMSO (high-priority) Documentation Fixes (https://github.com/mosdef-hub/gmso/pull/468)

ABC Modules Showing core properties of each, and see if these fit the needs of the OpenFF people. Trying to pitch the idea that this is what they are trying to propose in phase 1 (shared base object between the two ecosystems) Show extending the gmsobaseSite -> some basic site object (bead, etc) Sites Atom and AtomType Connections

XML Converters (Under development) Paramterized Parmed Structure: [Step One] https://gmso.mosdef.org/en/latest/_modules/gmso/external/convert_parmed.html Some research on what is necessary to for a foyer forcefield class to be a drop-in replacement. [Step Two]

Site is the object that represents any general interaction site in a molecular simulation. Sites have been designed to be as general as possible, making no assumptions about representing atoms or beads, or having mass or charge. That is, a Site can represent an atom in an atomistic system, a bead in a coarse-grained system, and much more. In general, a site in a molecular simulation can be of following types (braces represent potential form): Atom (AtomType) Bead (AtomType) Virtual Site (None) Point (None) In this post We will try to explain what each of these sites mean in terms of modeling them. From that we will try to derive the properties and methods for common abstract representation of a site.

Purpose: To provide a general in-memory representation of chemical topologies for molecular simulation. Chemical topology: A system with which to perform molecular simulation. This includes, but is not limited to, particle coordinates, particle connectivity, box information, and force field data (functional forms, parameters tagged with units, partial charges, etc.). Scope Create and manipulate chemical topologies Write chemical topologies to file-based chemical topology representations used by various simulation engines Interconvert between many file-based chemical topology representations without information loss Specifically do not support conversions between trajectory (i.e., output) file formats for analysis codes