Features
* Bond, angles, and dihedral parameters are now assigned based on definition specificity. Specificity is determined by the number “type” attributes (as opposed to “class” attributes) in a bond, angle, or dihedral definition. (160)
* This updates the previous behavior which assigned parameters based on the first matching definition regardless of specificity.
* Foyer now performs sanity checks for parameterization of angles, dihedrals, and impropers in a system. (155)
* By default, an error will be raised if parameters are not assigned to all angles and dihedrals in a system, and a warning will be raised if parameters are not assigned to all impropers in a system.
* The user can toggle these checks to raise warnings or errors as desired.
* Note that an error for non-parameterized bonds should already be raised by OpenMM.
* Residue-based atom-typing is now optional, though turned on by default. (159)
* This can be toggled through use of the `use_residue_map` argument to `Forcefield.apply`
* See 138 for more details
* Multiple DOIs can now be assigned to a single atom type definition. (168)
* Miscellaneous refactorization and syntax changes
* Atom-typing has been moved into a separate function: `Forcefield.run_atomtyping`. (159)
* The language in error messages and within the underlying code has been modified to refer to generic atom types as opposed to OPLS-specific types. (154)
Bug Fixes
* Fixed bug with atom-typing of polycyclic molecules (171)
* Our previous ring identification algorithm did not properly assign ring membership for all atoms within certain polycyclic molecules.
* A new algorithm for assigning ring membership has been implemented that resolves this issue.
* Residue-based atom-typing no longer raises an error for systems containing singular atoms. (151)
* With the addition of the residue map (138) to speed up atom-typing of non-unique molecules in the system, systems featuring singular atoms would cause an error to be raised due to a lack of bonded partners.
* This issue has been resolved, and systems featuring singular atoms can now be properly atom-typed using residue-based atom-typing.
* Spaces can now be included when defining multiple atom types within an `overrides` attribute. (181)
* Previously multiple atom type names could be listed within a single `overrides` attribute for an atom type definition in a force field XML file, but these had to be separated by a comma only and no space.
* e.g. Foyer would process a definition containing `overrides="opls_1, opls_2"` as only overriding `opls_1` due to the space between the two atom type names after the comma.
* Whitespace is now properly stripped from the `overrides` strings.
* A comma separated list of overrides is still expected; however, whitespace between each override will no longer cause unexpected behavior.
* Travis CI bug fixes (152)
* Multiple issues with Travis CI, Ruby, and MacOS when setting up the testing environment with Miniconda.
* These issues have been resolved.
Documentation
* DOIs have been added for most OPLS atom types that have SMARTS strings. Future SMARTS additions will require a corresponding DOI tag for merging (158)
* Sources, when found, were added to the atom type definitions in the OPLS force field XML through addition of a `doi` attribute.
* DOI sources could not be located for the following atom types:
* Alpha carbons in alkyl pyrroles (opls_678 and opls_679)
* Carbon atoms in cyclopropanes (opls_711, opls_712, opls_713)
* Carbon, oxygen, and hydrogen atoms in propylene carbonates (opls_771 – opls_779)
* Carbon and hydrogen atoms in alkynes (opls_925 – opls_930)
* References corresponding to these DOIs can be obtained in BibTeX format for systems atom-typed using the OPLS force field by providing a `references_file` argument to `Forcefield.apply`.
* The Foyer web page is now live at [http://mosdef-hub.github.io/foyer](http://mosdef-hub.github.io/foyer) (162, 175, 178)
* This website follows the same readthedocs theme as the mBuild package.
* We are currently experiencing issues with the stylesheet, so the website is not properly rendered. This issue should be resolved soon.
* Our documentation now includes a section on supported parameter definitions within a force field XML. (160)
* This can be found at [https://github.com/mosdef-hub/foyer/blob/master/docs/parameter_definitions.md](https://github.com/mosdef-hub/foyer/blob/master/docs/parameter_definitions.md) and on the website.