From 87a142a8e1d52637def52c1468be242838233351 Mon Sep 17 00:00:00 2001 From: davidlmobley Date: Thu, 3 Nov 2016 15:15:28 -0700 Subject: [PATCH 1/3] Break lines at sentences for better revision tracking --- The-SMIRFF-force-field-format.md | 65 ++++++++++++++++++++++---------- 1 file changed, 46 insertions(+), 19 deletions(-) diff --git a/The-SMIRFF-force-field-format.md b/The-SMIRFF-force-field-format.md index 154df17..40a6e61 100644 --- a/The-SMIRFF-force-field-format.md +++ b/The-SMIRFF-force-field-format.md @@ -1,10 +1,13 @@ # The Smirks Force Field (SMIRFF) format and its use -The SMIRFF format is based on the [`OpenMM`](http://openmm.org) [`ForceField`](http://docs.openmm.org/7.0.0/api-python/generated/simtk.openmm.app.forcefield.ForceField.html#simtk.openmm.app.forcefield.ForceField) class and provides an XML format for encoding force fields based on [SMIRKS](http://www.daylight.com/dayhtml/doc/theory/theory.smirks.html)-based chemical perception. While designed for [`OpenMM`](http://openmm.org), parameters encoded in this format can be applied to systems and then these systems converted via [`ParmEd`](http://parmed.github.io/ParmEd) and [`InterMol`](https://github.com/shirtsgroup/InterMol) for simulations in a variety of other simulation packages. +The SMIRFF format is based on the [`OpenMM`](http://openmm.org) [`ForceField`](http://docs.openmm.org/7.0.0/api-python/generated/simtk.openmm.app.forcefield.ForceField.html#simtk.openmm.app.forcefield.ForceField) class and provides an XML format for encoding force fields based on [SMIRKS](http://www.daylight.com/dayhtml/doc/theory/theory.smirks.html)-based chemical perception. +While designed for [`OpenMM`](http://openmm.org), parameters encoded in this format can be applied to systems and then these systems converted via [`ParmEd`](http://parmed.github.io/ParmEd) and [`InterMol`](https://github.com/shirtsgroup/InterMol) for simulations in a variety of other simulation packages. ## Basic structure -The SMIRFF format provides XML `ffxml` files that are parseable by the `ForceField` class of the `smarty.forcefield` module. These encode parameters for a force field based on a SMIRKS-based specification of the chemical environment the parameters are to be applied to. The file has tags corresponding to OpenMM force terms (`HarmonicBondForce`, `HarmonicAngleForce`, `PeriodicTorsionForce`, etc., as discussed in more detail below); these specify units used for the different constants provided for individual force terms, for example (see the [AlkEthOH example ffxml](https://github.com/open-forcefield-group/smarty/blob/master/smarty/data/forcefield/Frosst_AlkEtOH.ffxml)): +The SMIRFF format provides XML `ffxml` files that are parseable by the `ForceField` class of the `smarty.forcefield` module. +These encode parameters for a force field based on a SMIRKS-based specification of the chemical environment the parameters are to be applied to. +The file has tags corresponding to OpenMM force terms (`HarmonicBondForce`, `HarmonicAngleForce`, `PeriodicTorsionForce`, etc., as discussed in more detail below); these specify units used for the different constants provided for individual force terms, for example (see the [AlkEthOH example ffxml](https://github.com/open-forcefield-group/smarty/blob/master/smarty/data/forcefield/Frosst_AlkEtOH.ffxml)): ```XML ``` @@ -15,9 +18,12 @@ Under each of these force terms, there are tags for individual parameter lines s ``` -The first of these specifies the `[a,A:1]-[#6X4:2]-[a,A:3]` SMIRKS pattern for an angle, with a tetravalent carbon at the center with single bonds to two atoms of any type. Atoms are labeled 1, 2, and 3, with 2 being the central atom. Equilibrium angle values are provided, along with force constants (with units as given above). Additional tags `id` and `parent_id` are essentially "informational", with `id` essentially serving as a serial number for the parameter (it can be used to report on which parameters are assigned to a given molecule, for example) and `parent_id` ultimately being helpful in expressing relationships between parameters and tracking *parameter hierarchies*, though we do very little with this yet. +The first of these specifies the `[a,A:1]-[#6X4:2]-[a,A:3]` SMIRKS pattern for an angle, with a tetravalent carbon at the center with single bonds to two atoms of any type. +Atoms are labeled 1, 2, and 3, with 2 being the central atom. Equilibrium angle values are provided, along with force constants (with units as given above). +Additional tags `id` and `parent_id` are essentially "informational", with `id` essentially serving as a serial number for the parameter (it can be used to report on which parameters are assigned to a given molecule, for example) and `parent_id` ultimately being helpful in expressing relationships between parameters and tracking *parameter hierarchies*, though we do very little with this yet. -**SMIRFF parameters are hierarchical** in that parameters which come later in a file override those which come earlier if they match the same pattern. This can be seen in the example above, where the first line provides a generic angle parameter for any tetravalent carbon (single bond) angle, and the second line overrides this for the specific case of a hydrogen-(tetravalent carbon)-hydrogen angle. +**SMIRFF parameters are hierarchical** in that parameters which come later in a file override those which come earlier if they match the same pattern. + This can be seen in the example above, where the first line provides a generic angle parameter for any tetravalent carbon (single bond) angle, and the second line overrides this for the specific case of a hydrogen-(tetravalent carbon)-hydrogen angle. This hierarchical structure means that a typical parameter file will tend to have generic parameters early in the section for each force type, with more specialized parameters assigned later. @@ -25,9 +31,11 @@ This hierarchical structure means that a typical parameter file will tend to hav ## Functional forms, etc. -**Functional form**: The SMIRFF format specifies parameters; once specified, these are processed by the SMIRFF `ForceField` class and used to assign parameters to OpenMM Forces. This means that specific forces are generally implemented as discussed in the [OpenMM Documentation](http://docs.openmm.org/7.0.0/userguide/theory.html), see especially [Section 19 on Standard Forces](http://docs.openmm.org/7.0.0/userguide/theory.html#standard-forces) for functional forms. In some cases, typically for consistency with the AMBER force field philosophy motivating some of the authors, we do some manipulation of parameters from these files as discussed below in "Parameter sections". +**Functional form**: The SMIRFF format specifies parameters; once specified, these are processed by the SMIRFF `ForceField` class and used to assign parameters to OpenMM Forces. +This means that specific forces are generally implemented as discussed in the [OpenMM Documentation](http://docs.openmm.org/7.0.0/userguide/theory.html), see especially [Section 19 on Standard Forces](http://docs.openmm.org/7.0.0/userguide/theory.html#standard-forces) for functional forms. In some cases, typically for consistency with the AMBER force field philosophy motivating some of the authors, we do some manipulation of parameters from these files as discussed below in "Parameter sections". -**Charges**: In keeping with the AMBER force field philosophy, especially as implemented in small molecule force fields such as [GAFF](http://ambermd.org/antechamber/gaff.html), [GAFF2](https://mulan.swmed.edu/group/gaff.php), and [parm@Frosst](http://www.ccl.net/cca/data/parm_at_Frosst/), we at least initially treat partial charges as something to be obtained separately from the rest of the force field (bonds, angles, impropers, torsions [BAIT] and vdW terms), typically via QM calculations or a method such as Bayly's [AM1-BCC](https://dx.doi.org/10.1002/jcc.10128) approach, thus, for system setup we provide the option of specifying a charging method, though charges are not normally specified in the FFXML itself. For other force fields with "library"-style charges, we could introduce a new section providing specific charges via SMIRKS pattern, though this is not yet implemented. Bond charge corrections, however, are supported as we discuss below. +**Charges**: In keeping with the AMBER force field philosophy, especially as implemented in small molecule force fields such as [GAFF](http://ambermd.org/antechamber/gaff.html), [GAFF2](https://mulan.swmed.edu/group/gaff.php), and [parm@Frosst](http://www.ccl.net/cca/data/parm_at_Frosst/), we at least initially treat partial charges as something to be obtained separately from the rest of the force field (bonds, angles, impropers, torsions [BAIT] and vdW terms), typically via QM calculations or a method such as Bayly's [AM1-BCC](https://dx.doi.org/10.1002/jcc.10128) approach, thus, for system setup we provide the option of specifying a charging method, though charges are not normally specified in the FFXML itself. + For other force fields with "library"-style charges, we could introduce a new section providing specific charges via SMIRKS pattern, though this is not yet implemented. Bond charge corrections, however, are supported as we discuss below. ## Parameter sections @@ -59,7 +67,8 @@ Bond parameters are specified via the [`HarmonicBondForce`](http://docs.openmm.o ``` -**AMBER functional forms define the force constant `k` in a manner that differs by a factor of two---we do not use that convention here, electing to use the standard harmonic definition `U(r) = (k/2)*(r-length)^2` instead.** Thus, comparing a SMIRFF file to a corresponding AMBER parameter file or `.frcmod` will make it appear that force constants here are twice as large as they ought to be. +**AMBER functional forms define the force constant `k` in a manner that differs by a factor of two---we do not use that convention here, electing to use the standard harmonic definition `U(r) = (k/2)*(r-length)^2` instead.** +Thus, comparing a SMIRFF file to a corresponding AMBER parameter file or `.frcmod` will make it appear that force constants here are twice as large as they ought to be. ### ANGLE PARAMETERS @@ -72,7 +81,8 @@ Angle parameters are specified via the [`HarmonicAngleForce`](http://docs.openmm ``` -**AMBER functional forms drop the factor of 2 in the angle energy term, which we elect not to do here.** Thus, comparing a SMIRFF file to a corresponding AMBER parameter file or .frcmod will make it appear that force constants here are twice as large as they ought to be. +**AMBER functional forms drop the factor of 2 in the angle energy term, which we elect not to do here.** +Thus, comparing a SMIRFF file to a corresponding AMBER parameter file or .frcmod will make it appear that force constants here are twice as large as they ought to be. ### PROPER TORSIONS @@ -86,11 +96,16 @@ Torsions are implemented as a [`PeriodicTorsionForce`](http://docs.openmm.org/7. ``` -Here, child `Proper` tags specify at least `k1`, `phase1`, and `periodicity1` attributes for the corresponding parameters of the first force term applied to this torsion. However, additional values are allowed in the form kN, phaseN, and periodicityN, where all N values must be consecutive (e.g. no `k1` and `k3` values without a `k2` value) but `N` can go as high as necessary. +Here, child `Proper` tags specify at least `k1`, `phase1`, and `periodicity1` attributes for the corresponding parameters of the first force term applied to this torsion. +However, additional values are allowed in the form kN, phaseN, and periodicityN, where all N values must be consecutive (e.g. no `k1` and `k3` values without a `k2` value) but `N` can go as high as necessary. -Optionally, an `idivfN` attribute may be specified for each torsional term (for easier compatibility with AMBER files); this specifies a numerical value (in AMBER, always an integer) which is used as a divisor for the barrier height when assigning the torsion; i.e., a torsion with `idivf1="9"` is assigned a barrier height `k1` that is 1/9th the specified value. If `idivfN` is not specified, the barrier height is applied as stated. +Optionally, an `idivfN` attribute may be specified for each torsional term (for easier compatibility with AMBER files); this specifies a numerical value (in AMBER, always an integer) which is used as a divisor for the barrier height when assigning the torsion; i.e., a torsion with `idivf1="9"` is assigned a barrier height `k1` that is 1/9th the specified value. +If `idivfN` is not specified, the barrier height is applied as stated. -In the future, we may switch to a model where torsional barriers are [automatically divided by the number of torsions along a bond](https://github.com/open-forcefield-group/smarty/issues/131), effectively resulting in the torsional barrier being the average of all barriers applied to that bond, rather than the current model where barriers are summed. (Barrier heights would need to be increased accordingly.) This would result in better handling of some cases where a small change in a molecule (such as a change in tautomer) could currently (as in AMBER) result in a dramatically different applied barrier height because of a change in the number of torsions passing through that bond. The averaging approach would make it easier to avoid this problem without requiring as many different torsional terms. +In the future, we may switch to a model where torsional barriers are [automatically divided by the number of torsions along a bond](https://github.com/open-forcefield-group/smarty/issues/131), effectively resulting in the torsional barrier being the average of all barriers applied to that bond, rather than the current model where barriers are summed. +(Barrier heights would need to be increased accordingly.) +This would result in better handling of some cases where a small change in a molecule (such as a change in tautomer) could currently (as in AMBER) result in a dramatically different applied barrier height because of a change in the number of torsions passing through that bond. +The averaging approach would make it easier to avoid this problem without requiring as many different torsional terms. ### IMPROPER TORSIONS @@ -100,12 +115,15 @@ Impropers are applied in the same manner as proper torsions, via `PeriodicTorsio ... ``` -**Improper torsions deviate profoundly from AMBER handling of impropers** in two ways. First, to eliminate ambiguity, we treat impropers as a [trefoil](https://upload.wikimedia.org/wikipedia/commons/thumb/5/5c/Trefoil_knot_left.svg/2000px-Trefoil_knot_left.svg.png) and apply the same set of parameters to all six paths around the trefoil. *Because of this, all barrier heights are divided by six before we apply them*, for consistency with AMBER force fields. Second, the *second* atom in an improper (in the example above, the trivalent carbon) is the central atom in the trefoil. +**Improper torsions deviate profoundly from AMBER handling of impropers** in two ways. +First, to eliminate ambiguity, we treat impropers as a [trefoil](https://upload.wikimedia.org/wikipedia/commons/thumb/5/5c/Trefoil_knot_left.svg/2000px-Trefoil_knot_left.svg.png) and apply the same set of parameters to all six paths around the trefoil. +*Because of this, all barrier heights are divided by six before we apply them*, for consistency with AMBER force fields. Second, the *second* atom in an improper (in the example above, the trivalent carbon) is the central atom in the trefoil. ### SPECIAL SECTIONS **Bond charge corrections** -Bond charge corrections (along the lines of Christopher Bayly's bond charge corrections in [AM1-BCC](https://dx.doi.org/10.1002/jcc.10128)) can be applied via a `BondChargeCorrections` tag with children specifying specific `BondChargeCorrection` terms. Here is an example not intended for actual use: +Bond charge corrections (along the lines of Christopher Bayly's bond charge corrections in [AM1-BCC](https://dx.doi.org/10.1002/jcc.10128)) can be applied via a `BondChargeCorrections` tag with children specifying specific `BondChargeCorrection` terms. +Here is an example not intended for actual use: ```XML @@ -136,7 +154,8 @@ can be replaced by a single parameter line: ... ``` -This allows specification of force constants and lengths for bond orders 1 and 2, and then interpolation between those based on the partial bond order. Currently the Wiberg bond order is used, which will be obtained automatically from an AM1-based charge calculation using the OpenEye toolkits if a beta version (or later) of the October 2016 toolkits is used. +This allows specification of force constants and lengths for bond orders 1 and 2, and then interpolation between those based on the partial bond order. +Currently the Wiberg bond order is used, which will be obtained automatically from an AM1-based charge calculation using the OpenEye toolkits if a beta version (or later) of the October 2016 toolkits is used. Important usage notes: * An interpolation scheme must be specified in the `HarmonicBondForce` attributes; currently only `interpolate-linear` is supported, though a spline interpolation may be preferable (this needs to be explored) @@ -145,8 +164,10 @@ Important usage notes: ### Aromaticity models -Before conduct SMIRKS substructure searches, molecules are prepared by applying one of OpenEye's aromaticity models, with the default model used unless otherwise requested. Alternate aromaticity models can be requested by the force field, such as -`` used by SMIRFF99Frosst (a choice by Christopher Bayly to simplify handling of certain heteroaromatic compounds). Any of the names of the [aromaticity models available in the OpenEye toolkit](https://docs.eyesopen.com/toolkits/python/oechemtk/aromaticity.html) can be used. +Before conduct SMIRKS substructure searches, molecules are prepared by applying one of OpenEye's aromaticity models, with the default model used unless otherwise requested. +Alternate aromaticity models can be requested by the force field, such as +`` used by SMIRFF99Frosst (a choice by Christopher Bayly to simplify handling of certain heteroaromatic compounds). +Any of the names of the [aromaticity models available in the OpenEye toolkit](https://docs.eyesopen.com/toolkits/python/oechemtk/aromaticity.html) can be used. ### Future plans @@ -185,7 +206,9 @@ This example can essentially trivially be extended to handle the case of beginni The SMIRFF_simulation example in the examples directory shows how to extend the example above to simulate this molecule in the gas phase. -`createSystem()` can also handle a system consisting of a mixture of molecules; we've tested it on cyclohexane/ethanol and propane/methanol/butanol mixtures for example. As input it is necessary to provide a Topology file representing the system, and a list of OpenEye molecules for the components of that Topology. So, for example, one can read a PDB file describing a mixture and provide OpenEye molecules for the components (generated by the Mobleylab's [SolvationToolkit](https://github.com/MobleyLab/SolvationToolkit), for example) and create a system from that. +`createSystem()` can also handle a system consisting of a mixture of molecules; we've tested it on cyclohexane/ethanol and propane/methanol/butanol mixtures for example. +As input it is necessary to provide a Topology file representing the system, and a list of OpenEye molecules for the components of that Topology. +So, for example, one can read a PDB file describing a mixture and provide OpenEye molecules for the components (generated by the Mobleylab's [SolvationToolkit](https://github.com/MobleyLab/SolvationToolkit), for example) and create a system from that. `createSystem()` allows the user to specify a choice of charge model, among other properties. Consult its help in python for more information. @@ -194,12 +217,16 @@ One important note is that the OpenEye molecules currently must have atom names, ### A remark about parameter availability -`ForceField` will currently raise an exception if any parameters are missing where expected for your system---i.e. if a bond is assigned no parameters, an exception will be raised. However, use of generic parameters (i.e. `[*:1]~[*:2]` for a bond) in your FFXML will result in parameters being assigned everywhere, bypassing this exception. So use generics sparingly unless it is your intention to provide generics that should be used. +`ForceField` will currently raise an exception if any parameters are missing where expected for your system---i.e. if a bond is assigned no parameters, an exception will be raised. +However, use of generic parameters (i.e. `[*:1]~[*:2]` for a bond) in your FFXML will result in parameters being assigned everywhere, bypassing this exception. +So use generics sparingly unless it is your intention to provide generics that should be used. ## Requirements -Requirements match those of the SMARTY package and will be provided in more detail on the main page for SMARTY in SMARTY's `README.md`. Currently, [OpenEye toolkits](http://www.eyesopen.com/toolkit-development) (free for academic use, but they require a license) are utilized for most of our chemistry. [OpenMM](http://openmm.org) is also required, as are a variety of other relatively standard python packages and other toolkits available via [`conda`](http://conda.pydata.org/docs/building/meta-yaml.html). +Requirements match those of the SMARTY package and will be provided in more detail on the main page for SMARTY in SMARTY's `README.md`. +Currently, [OpenEye toolkits](http://www.eyesopen.com/toolkit-development) (free for academic use, but they require a license) are utilized for most of our chemistry. +[OpenMM](http://openmm.org) is also required, as are a variety of other relatively standard python packages and other toolkits available via [`conda`](http://conda.pydata.org/docs/building/meta-yaml.html). The easiest way to install SMARTY along with its dependencies is via `conda`: ```bash From 72acf5b568b1cb679b1b7b164aa8d58cf4492f2d Mon Sep 17 00:00:00 2001 From: davidlmobley Date: Thu, 3 Nov 2016 15:39:12 -0700 Subject: [PATCH 2/3] Update docs to handle other future directions/generalizations; remove parent_id and id from most examples --- The-SMIRFF-force-field-format.md | 65 ++++++++++++++++++++++---------- 1 file changed, 45 insertions(+), 20 deletions(-) diff --git a/The-SMIRFF-force-field-format.md b/The-SMIRFF-force-field-format.md index 40a6e61..88506ac 100644 --- a/The-SMIRFF-force-field-format.md +++ b/The-SMIRFF-force-field-format.md @@ -15,12 +15,11 @@ which introduces following `Angle` terms which will use units of degrees for the Under each of these force terms, there are tags for individual parameter lines such as these: ```XML - - + + ``` The first of these specifies the `[a,A:1]-[#6X4:2]-[a,A:3]` SMIRKS pattern for an angle, with a tetravalent carbon at the center with single bonds to two atoms of any type. Atoms are labeled 1, 2, and 3, with 2 being the central atom. Equilibrium angle values are provided, along with force constants (with units as given above). -Additional tags `id` and `parent_id` are essentially "informational", with `id` essentially serving as a serial number for the parameter (it can be used to report on which parameters are assigned to a given molecule, for example) and `parent_id` ultimately being helpful in expressing relationships between parameters and tracking *parameter hierarchies*, though we do very little with this yet. **SMIRFF parameters are hierarchical** in that parameters which come later in a file override those which come earlier if they match the same pattern. This can be seen in the example above, where the first line provides a generic angle parameter for any tetravalent carbon (single bond) angle, and the second line overrides this for the specific case of a hydrogen-(tetravalent carbon)-hydrogen angle. @@ -48,8 +47,8 @@ Before getting in to individual sections, it's worth noting that the XML parser Nonbonded parameters (currently, Lennard-Jones parameters) are specified via the [`NonbondedForce`](http://docs.openmm.org/7.0.0/userguide/theory.html#nonbondedforce) tag with sub-tags for individual `Atom` entries, such as: ```XML - - + + ... Scaling terms for 1-4 interactions should be specified in attributes for the `NonbondedForce` tag, along with units. @@ -61,8 +60,8 @@ For compatibility, the size property of an atom can be specified either via prov Bond parameters are specified via the [`HarmonicBondForce`](http://docs.openmm.org/7.0.0/userguide/theory.html#harmonicbondforce) tag with individual `Bond` tags providing equilibrium bond length `length` and force constant `k` values for specific bonds, for example: ```XML - - + + ... ``` @@ -75,8 +74,8 @@ Thus, comparing a SMIRFF file to a corresponding AMBER parameter file or `.frcmo Angle parameters are specified via the [`HarmonicAngleForce`](http://docs.openmm.org/7.0.0/userguide/theory.html#harmonicangleforce) tag with individual `Angle` tags providing parameters (equilibrium angle `angle` and force constant `k`), as in this example: ```XML - - + + ... ``` @@ -89,9 +88,9 @@ Thus, comparing a SMIRFF file to a corresponding AMBER parameter file or .frcmod Torsions are implemented as a [`PeriodicTorsionForce`](http://docs.openmm.org/7.0.0/userguide/theory.html#periodictorsionforce) tag with child tags for `Proper` (discussed here) and `Improper` (discussed below) parameters, for example: ``` - + ... - + ... ``` @@ -111,7 +110,7 @@ The averaging approach would make it easier to avoid this problem without requir Impropers are applied in the same manner as proper torsions, via `PeriodicTorsionForce`, but with the `Improper` tag, as in: ```XML: - + ... ``` @@ -126,9 +125,9 @@ Bond charge corrections (along the lines of Christopher Bayly's bond charge corr Here is an example not intended for actual use: ```XML - - - + + + ``` The charge model specified must be a method understood by the OpenEye toolkits, and the charge correction `increment` (in units of proton charge) will be applied on top of this by subtracting `increment` from the atom tagged as 1 and adding it to the atom tagged as 2. @@ -142,16 +141,16 @@ Partial bond orders can be used to allow interpolation of parameters. For exampl ```XML ... - - - + + + ... ``` can be replaced by a single parameter line: ```XML ... - + ... ``` This allows specification of force constants and lengths for bond orders 1 and 2, and then interpolation between those based on the partial bond order. @@ -169,7 +168,23 @@ Alternate aromaticity models can be requested by the force field, such as `` used by SMIRFF99Frosst (a choice by Christopher Bayly to simplify handling of certain heteroaromatic compounds). Any of the names of the [aromaticity models available in the OpenEye toolkit](https://docs.eyesopen.com/toolkits/python/oechemtk/aromaticity.html) can be used. -### Future plans +### Future advanced features + +At present, the SMIRFF format basically defaults to AMBER- or OpenMM-style decisions on many issues. +For example, AMBER-style (Lorentz-Berthelot) combining rules are used, and the AMBER force field functional form. +Angles potentials are assumed to be harmonic. +However, we have plans to support other combination rules, functional forms, and angle potentials. +In keeping with the above, whole-force field decisions will be handled as attributes of the SMIRFF tag. +For example, alternate combination rules or functional forms might be handled as follows: +* Geometric mean combining rule: `` +* A Halgren buffered 14-7 potential for vdW could be handled as `` +* Selection of the type of angle force applied would be handled in a similar manner, via an `AngleForce="harmonic"` tag or similar. [This feature is being planned.](https://github.com/open-forcefield-group/smarty/issues/179) + + +[Generalized Born parameters and models will also be supported](https://github.com/open-forcefield-group/smarty/issues/165) and implementation is being planned. + + +### Additional plans for future development See the Issue tracker for a more thorough list, though some major areas are highlighted here: * Exploring how use of partial bond order can simplify the environments needed @@ -214,6 +229,16 @@ So, for example, one can read a PDB file describing a mixture and provide OpenEy One important note is that the OpenEye molecules currently must have atom names, hence the [`OETriposAtomNames`](https://docs.eyesopen.com/toolkits/python/oechemtk/OEChemFunctions/OETriposAtomNames.html) above. +### `id` and other XML attributes + +In general, other XML attributes can be specified and will be ignored by `ForceField` unless they are specifically handled by the parser (and specified in this document). + +One attribute we have found helpful in actual parsing is the `id` attribute for a specific parameter line, and we *recommend* that SMIRFF forcefields utilize this as effectively a parameter serial number, such as in: +```XML + +``` +Some functionality in `ForceField`, such as `ForceField.labelMolecules`, looks for the `id` attribute. +Without this attribute, there is no way to uniquely identify a specific parameter line in the XML file without referring to it by its smirks string, and since some smirks strings can become long and relatively unwieldly (especially for torsions) this provides a more human- and search-friendly way of referring to specific sets of parameters. ### A remark about parameter availability From 3ae9bcf5cb4f633980f4190b65c971794f81a51f Mon Sep 17 00:00:00 2001 From: davidlmobley Date: Thu, 3 Nov 2016 16:12:13 -0700 Subject: [PATCH 3/3] Fix missing XML marker --- The-SMIRFF-force-field-format.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/The-SMIRFF-force-field-format.md b/The-SMIRFF-force-field-format.md index 88506ac..a7e8083 100644 --- a/The-SMIRFF-force-field-format.md +++ b/The-SMIRFF-force-field-format.md @@ -86,7 +86,7 @@ Thus, comparing a SMIRFF file to a corresponding AMBER parameter file or .frcmod ### PROPER TORSIONS Torsions are implemented as a [`PeriodicTorsionForce`](http://docs.openmm.org/7.0.0/userguide/theory.html#periodictorsionforce) tag with child tags for `Proper` (discussed here) and `Improper` (discussed below) parameters, for example: -``` +```XML ...