Software Open Access
David L. Mobley; Jeff Wagner; John Chodera; Caitlin Bannan; Andrea Rizzi; Camila; Christopher Bayly; SimonBoothroyd; Nathan M. Lim; Victoria Lim; Yutong Zhao; Lee-Ping
This update contains performance enhancements that significantly reduce the time to create OpenMM systems for topologies containing many molecules via
This update also introduces the SMIRNOFF 0.3 specification. The spec update is the result of discussions about how to handle the evolution of data and parameter types as further functional forms are added to the SMIRNOFF spec.
We provide methods to convert SMIRNOFF 0.1 and 0.2 forcefields written with the XML serialization (
.offxml) to the SMIRNOFF 0.3 specification. These methods are called automatically when loading a serialized SMIRNOFF data representation written in the 0.1 or 0.2 specification. This functionality allows the toolkit to continue to read files containing SMIRNOFF 0.2 spec force fields, and also implements backwards-compatibility for SMIRNOFF 0.1 spec force fields.
SMIRNOFF 0.3 specification updates
WARNING: The SMIRNOFF 0.1 spec did not contain fields for several energy-determining parameters that are exposed in later SMIRNOFF specs. Thus, when reading SMIRNOFF 0.1 spec data, the toolkit must make assumptions about the values that should be added for the newly-required fields. The values that are added include 1-2, 1-3 and 1-5 scaling factors, cutoffs, and long-range treatments for nonbonded interactions. Each assumption is printed as a warning during the conversion process. Please carefully review the warning messages to ensure that the conversion is providing your desired behavior.
SMIRNOFFtag, containing information like
Date, still has a version (currently 0.3). But, to allow for independent development of individual parameter types, each section (such as
Angles, etc) now has its own version as well (currently all 0.3).
1.526*angstrom, instead of storing the unit separately in the section header.
ImproperTorsionstags is no longer
charmm, but is rather
k*(1+cos(periodicity*theta-phase)). It was pointed out to us that CHARMM-style torsions deviate from this formula when the periodicity of a torsion term is 0, and we do not intend to reproduce that behavior.
convert_0_2_smirnoff_to_0_3, which takes a SMIRNOFF 0.2-spec data dict, and updates it to 0.3. This function is called automatically when creating a
ForceFieldfrom a SMIRNOFF 0.2 spec OFFXML file.
convert_0_1_smirnoff_to_0_2, which takes a SMIRNOFF 0.1-spec data dict, and updates it to 0.2. This function is called automatically when creating a
ForceFieldfrom a SMIRNOFF 0.1 spec OFFXML file.
delete_cosmetic_attributefunctions. Once created, cosmetic attributes can be accessed and modified as attributes of the underlying object (eg.
ParameterType.my_cosmetic_attrib = 'blue'). These functions are experimental, and we are interested in feedback on how cosmetic attribute handling could be improved. (See Issue #338). Note that if a new cosmetic attribute is added to an object without using these functions, it will not be recognized by the toolkit and will not be written out during serialization.
Datetags are now kept during SMIRNOFF data I/O. If multiple data sources containing these fields are read, the values are concatenated using "AND" as a separator.
ForceField.to_filehave had the default value of their
discard_cosmetic_attributeskwarg set to False.
ParameterTypeconstructors now expect the
versionkwarg (per the SMIRNOFF spec change above). This requirement can be skipped by providing the kwarg
ParameterTypefunctions no longer handle
X_unitattributes in SMIRNOFF data (per the SMIRNOFF spec change above).
utilities/convert_frosstare now deprecated. This functionality is important for provenance and will be migrated to the
openforcefield/smirnoff99Frosstrepository in the coming weeks.
ParameterType ._REQUIRED_SPEC_ATTRIBS, to better parallel the structure of the
ParameterType ._OPTIONAL_SPEC_ATTRIBS, to better parallel the structure of the