Software Open Access

# openforcefield/openforcefield: 0.6.0 Library Charges

Jeff Wagner; David L. Mobley; John Chodera; Caitlin Bannan; Andrea Rizzi; Camila; Christopher Bayly; Nathan M. Lim; Victoria Lim; Sukanya Sasmal; Jaime Rodríguez-Guerra; Yutong Zhao; Lee-Ping

### DataCite XML Export

<?xml version='1.0' encoding='utf-8'?>
<identifier identifierType="DOI">10.5281/zenodo.3541134</identifier>
<creators>
<creator>
<creatorName>Jeff Wagner</creatorName>
<affiliation>@openforcefield</affiliation>
</creator>
<creator>
<creatorName>David L. Mobley</creatorName>
<affiliation>University of California, Irvine</affiliation>
</creator>
<creator>
<creatorName>John Chodera</creatorName>
<affiliation>Memorial Sloan Kettering Cancer Center</affiliation>
</creator>
<creator>
<creatorName>Caitlin Bannan</creatorName>
<affiliation>OpenEye Scientific Software</affiliation>
</creator>
<creator>
<creatorName>Andrea Rizzi</creatorName>
<affiliation>@choderalab</affiliation>
</creator>
<creator>
<creatorName>Camila</creatorName>
</creator>
<creator>
<creatorName>Christopher Bayly</creatorName>
<affiliation>OpenEye Scientific Software</affiliation>
</creator>
<creator>
<creatorName>Nathan M. Lim</creatorName>
<affiliation>@MobleyLab</affiliation>
</creator>
<creator>
<creatorName>Victoria Lim</creatorName>
<affiliation>@MobleyLab at UC Irvine</affiliation>
</creator>
<creator>
<creatorName>Sukanya Sasmal</creatorName>
<affiliation>UC Irvine</affiliation>
</creator>
<creator>
<creatorName>Jaime Rodríguez-Guerra</creatorName>
<affiliation>@volkamerlab + @choderalab</affiliation>
</creator>
<creator>
<creatorName>Yutong Zhao</creatorName>
</creator>
<creator>
<creatorName>Lee-Ping</creatorName>
</creator>
</creators>
<titles>
<title>openforcefield/openforcefield: 0.6.0 Library Charges</title>
</titles>
<publisher>Zenodo</publisher>
<publicationYear>2019</publicationYear>
<dates>
<date dateType="Issued">2019-11-13</date>
</dates>
<resourceType resourceTypeGeneral="Software"/>
<alternateIdentifiers>
<alternateIdentifier alternateIdentifierType="url">https://zenodo.org/record/3541134</alternateIdentifier>
</alternateIdentifiers>
<relatedIdentifiers>
<relatedIdentifier relatedIdentifierType="URL" relationType="IsSupplementTo">https://github.com/openforcefield/openforcefield/tree/0.6.0</relatedIdentifier>
<relatedIdentifier relatedIdentifierType="DOI" relationType="IsVersionOf">10.5281/zenodo.597754</relatedIdentifier>
</relatedIdentifiers>
<version>0.6.0</version>
<rightsList>
<rights rightsURI="info:eu-repo/semantics/openAccess">Open Access</rights>
</rightsList>
<descriptions>
<description descriptionType="Abstract">0.6.0
&lt;p&gt;This release adds support for a new SMIRKS-based charge assignment method, &lt;a href="https://open-forcefield-toolkit.readthedocs.io/en/latest/smirnoff.html#librarycharges-library-charges-for-polymeric-residues-and-special-solvent-models"&gt;Library Charges&lt;/a&gt;. The addition of more charge assignment methods opens the door for new types of experimentation, but also introduces several complex behaviors and failure modes. Accordingly, we have made changes to the charge assignment infrastructure to check for cases when partial charges do not sum to the formal charge of the molecule, or when no charge assignment method is able to generate charges for a molecule. More detailed explanations of the new errors that may be raised and keywords for overriding them are in the "Behavior Changed" section below.&lt;/p&gt;
&lt;p&gt;With this release, we update &lt;code&gt;test_forcefields/tip3p.offxml&lt;/code&gt; to be a working example of assigning LibraryCharges. However, we do not provide any force field files to assign protein residue &lt;code&gt;LibraryCharges&lt;/code&gt;. If you are interested in translating an existing protein FF to SMIRNOFF format or developing a new one, please feel free to contact us on the &lt;a href="https://github.com/openforcefield/openforcefield/issues"&gt;Issue tracker&lt;/a&gt; or open a &lt;a href="https://github.com/openforcefield/openforcefield/pulls"&gt;Pull Request&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;A richer version of these release notes with live links to API documentation is available on &lt;a href="https://open-forcefield-toolkit.readthedocs.io/en/latest/releasehistory.html"&gt;our ReadTheDocs page&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;Please report bugs, request features, or ask questions through our &lt;a href="https://github.com/openforcefield/openforcefield/issues"&gt;issue tracker&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Please note that there may still be some changes to the API prior to a stable 1.0.0 release.&lt;/strong&gt;&lt;/p&gt;
New features
&lt;ul&gt;
&lt;li&gt;&lt;p&gt;PR #433 : Closes Issue #25 by adding initial support for the &lt;a href="https://open-forcefield-toolkit.readthedocs.io/en/latest/smirnoff.html#librarycharges-library-charges-for-polymeric-residues-and-special-solvent-models"&gt;LibraryCharges tag in the SMIRNOFF specification&lt;/a&gt; using &lt;code&gt;LibraryChargeHandler&lt;/code&gt;. For a molecule to have charges assigned using Library Charges, all of its atoms must be covered by at least one &lt;code&gt;LibraryCharge&lt;/code&gt;. If an atom is covered by multiple &lt;code&gt;LibraryCharge&lt;/code&gt; s, then the last &lt;code&gt;LibraryCharge&lt;/code&gt; matched will be applied (per the hierarchy rules in the SMIRNOFF format).&lt;/p&gt;
&lt;p&gt;This functionality is thus able to apply per-residue charges similar to those in traditional protein force fields. At this time, there is no concept of "residues" or "fragments" during parametrization, so it is not possible to assign charges to &lt;em&gt;some&lt;/em&gt; atoms in a molecule using &lt;code&gt;LibraryCharge&lt;/code&gt; s, but calculate charges for other atoms in the same molecule using a different method. To assign charges to a protein, LibraryCharges SMARTS must be provided for the residues and protonation states in the molecule, as well as for any capping groups
and post-translational modifications that are present.&lt;/p&gt;
&lt;p&gt;It is valid for &lt;code&gt;LibraryCharge&lt;/code&gt; SMARTS to &lt;em&gt;partially&lt;/em&gt; overlap one another. For example, a molecule consisting of atoms &lt;code&gt;A-B-C&lt;/code&gt; connected by single bonds could be matched by a SMIRNOFF &lt;code&gt;LibraryCharges&lt;/code&gt; section containing two &lt;code&gt;LibraryCharge&lt;/code&gt; SMARTS: &lt;code&gt;A-B&lt;/code&gt; and &lt;code&gt;B-C&lt;/code&gt;. If listed in that order, the molecule would be assigned the &lt;code&gt;A&lt;/code&gt; charge from the &lt;code&gt;A-B&lt;/code&gt; &lt;code&gt;LibraryCharge&lt;/code&gt; element and the &lt;code&gt;B&lt;/code&gt; and &lt;code&gt;C&lt;/code&gt; charges from the &lt;code&gt;B-C&lt;/code&gt; element. In testing, these types of partial overlaps were found to frequently be sources of undesired behavior, so it is recommended that users define whole-molecule &lt;code&gt;LibraryCharge&lt;/code&gt; SMARTS whenever possible.&lt;/p&gt;
&lt;/li&gt;
&lt;li&gt;&lt;p&gt;PR #455 : Addresses #393 by adding &lt;code&gt;ParameterHandler.attribute_is_cosmetic&lt;/code&gt; and &lt;code&gt;ParameterType.attribute_is_cosmetic&lt;/code&gt;, which return True if the provided attribute name is defined for the queried object but does not correspond to an allowed value in the SMIRNOFF spec.&lt;/p&gt;
&lt;/li&gt;
&lt;/ul&gt;
Behavior changed
&lt;ul&gt;
&lt;li&gt;PR #433 : If a molecule can not be assigned charges by any charge-assignment method, an &lt;code&gt;openforcefield.typing.engines.smirnoff.parameters.UnassignedMoleculeChargeException&lt;/code&gt; will be raised. Previously, creating a system without either &lt;code&gt;ToolkitAM1BCCHandler&lt;/code&gt; or the &lt;code&gt;charge_from_molecules&lt;/code&gt; keyword argument to &lt;code&gt;ForceField.create_openmm_system&lt;/code&gt; would produce a system where the molecule has zero charge on all atoms. However, given that we will soon be adding more options for charge assignment, it is important that failures not be silent. Molecules with zero charge can still be produced by setting the &lt;code&gt;Molecule.partial_charges&lt;/code&gt; array to be all zeroes, and including the molecule in the &lt;code&gt;charge_from_molecules&lt;/code&gt; keyword argument to &lt;code&gt;create_openmm_system&lt;/code&gt;.&lt;/li&gt;
&lt;li&gt;PR #433 : Due to risks introduced by permitting charge assignment using partially-overlapping &lt;code&gt;LibraryCharge&lt;/code&gt; s, the toolkit will now raise a &lt;code&gt;openforcefield.typing.engines.smirnoff.parameters.NonIntegralMoleculeChargeException&lt;/code&gt; if the sum of partial charges on a molecule are found to be more than 0.01 elementary charge units different than the molecule's formal charge. This exception can be overridden by providing the &lt;code&gt;allow_nonintegral_charges=True&lt;/code&gt; keyword argument to &lt;code&gt;ForceField.create_openmm_system&lt;/code&gt;.&lt;/li&gt;
&lt;/ul&gt;
&lt;ul&gt;
&lt;li&gt;PR #430 : Added test for Wiberg Bond Order implemented in OpenEye Toolkits. Test molecules taken from  DOI:10.5281/zenodo.3405489 . Added by @sukanyasasmal .&lt;/li&gt;
&lt;/ul&gt;
Bugfixes
&lt;ul&gt;
&lt;li&gt;PR #431 : Fixes an issue where &lt;code&gt;ToolkitWrapper&lt;/code&gt; objects would improperly search for functionality in the &lt;code&gt;GLOBAL_TOOLKIT_REGISTRY&lt;/code&gt;, even though a specific &lt;code&gt;ToolkitRegistry&lt;/code&gt; was requested for an operation.&lt;/li&gt;
&lt;li&gt;PR #439 : Fixes &lt;code&gt;Issue #438 &amp;lt;https://github.com/openforcefield/openforcefield/issues/438&amp;gt;&lt;/code&gt;_, by replacing call to NetworkX &lt;code&gt;Graph.node&lt;/code&gt; with call to &lt;code&gt;Graph.nodes&lt;/code&gt;, per &lt;a href="https://networkx.github.io/documentation/stable/release/release_2.4.html"&gt;2.4 migration guide&lt;/a&gt;.&lt;/li&gt;
&lt;/ul&gt;
Files modified
&lt;ul&gt;
&lt;li&gt;PR #433 : Updates the previously-nonfunctional &lt;code&gt;test_forcefields/tip3p.offxml&lt;/code&gt; to a functional state by updating it to the SMIRNOFF 0.3 specification, and specifying atomic charges using the &lt;code&gt;LibraryCharges&lt;/code&gt; tag.&lt;/li&gt;
&lt;/ul&gt;</description>
</descriptions>
</resource>

4,891
39
views