-Forcefields are a crucial ingredient of Molecular Dynamics (MD) simulations, describing the types and parameters of interactions between the simulated particles. These parameter sets, however, are typically specific to the molecule in which the atoms appears, where within the molecule the atom is positioned, the phase or state point of the system, as well as the simulator tool in use. This makes choosing the correct parameter values a tedious and error prone task. Forcefield parameters, furthermore, are often hard to locate: some are published in scientific papers, others come with MD tools, often with no or ambiguous documentation on their applicability. In this paper, we present a framework that aims to solve this data management issue, proposing a common format for forcefields that is self-documenting with machine readable, declarative usage rules. We believe that processes and tools that are commonly used today in software development (e.g, unit testing, verification and validation, continuous integration, and version control) are, with proper infrastructure support, applicable to forcefield development, as well. The paper describes how such an infrastructure can tackle managing and evolving forcefields by the MD community, and proposes a way to encourage and incentivize involvement by the stakeholders.
Molecular simulation plays a key role in understanding
the atomistic and molecular level interactions that
underlie many natural and man-made materials and
processes. [
Fig. 1. Perfluorobutane, CF3-CF2-CF2-CF3, molecule shown with ball and stick representation.
to spend time developing the forcefield parameters,
determining which parameters to use (i.e., atom-typing)
is still often a tedious and error prone task. In many
forcefields, the appropriate interaction parameters will
depend on the local topological environment of atoms.
For example, the non-bonded interactions of carbon
atoms in perfluoroalkanes (PFA) are typically
different for terminal carbons verses “middle” carbons [
Most research groups use some combination of hand
parameterization and logic based codes to facilitate the
process of atom-typing. Identifying atom types by hand,
while easy for small/simple molecules and important for
validation, becomes impractical for large molecules or
systems with significant heterogeneity. For molecules
with only a few atomic species and little variability, ad
hoc, logic-based codes are relatively straightforward to
write and test. However, as the number of unique atom
types increases, properly defining the appropriate if/else
statements required in most logic codes becomes
onerous, even for people who are well versed in programming
and have domain expertise in molecular modeling. Also,
nested logic statements are often difficult to adequately
test and debug and thus introduce a potential source
of error. Since ad hoc codes are not typically released
to the general community, any errors in the code may
go undiscovered and thus data based on flawed
atomtyping may appear in published scientific literature. To
address this, several community tools and approaches
have been developed to aid in atom-typing [
To address these issues, we are developing a new framework for atom-typing, based upon first order logic over graph structures. The novelty of our approach lies in the declarative annotation syntax that allows for 1) decoupling the definition of forcefield-specific atomtyping rules from how a forcefield-agnostic tool uses these annotations to automatically compute the atomtyping of complex molecular systems, and 2) formally verifying and automatically validating annotated forcefields. Specifically, we proposed to: establish a forcefield agnostic (i:e:, general) formalism to express the chemical context in which a particular force field entry is applicable (i:e:, forcefield usage semantics); develop a tool suite that automates atom-typing of molecular structures using the semantics-annotated forcefields; and establish a development process to create, incrementally extend, and evolve annotated forcefields, providing tools for automated verification, validation, and continuous integration techniques.
An important goal of the project is to disseminate results and to foster community involvement through the creation of a centralized online forcefield repository containing the formally annotated forcefields, documentation of how to annotate forcefields, along with files for benchmarking and validation of the atom-typing software. Given the importance of accurately applying forcefields to molecular simulation, the new atom-typing framework developed in this work has the potential to significantly impact the community, affording researchers greater confidence in the model parameters used in their studies, eliminate the need to develop ad hoc atom-typing codes, make forcefield parameter usage clearer, and significantly reduce incorrect atom-typing as a source of error and inconsistency in published results.
In our vision, forcefield definitions are not just sets of tables with numerical data, but as unambiguous, wellstructured documents with rich metadata, including the formal description of the chemical context in which the particular parameter values can be applied. In the future, the tedious and error prone task of manually atom-typing and parameterizing complex molecular models (inputs to simulators) will be eliminated, and replaced by the automated process that relies on the machine-readable forcefield usage semantics.
We envision forcefields as dynamic data entities that evolve over time: parameterizations of additional chemical species are added, already supported chemical species are specialized, and parameter values are tweaked for better modeling of the chemical interactions. Forcefield definitions will be maintained by online communities and hosted at shared repositories with version control capabilities. These online repositories will also support continuous integration (CI), i:e:, automated verification, validation, and testing of the forcefields as they evolve.
We believe that the developers of forcefield definitions deserve credit for their efforts. The online repositories will generate permanent URL links per forcefield versions, as well as document object identifiers (DOI) which allow unambiguously referencing these data artifacts, and properly citing them in scientific publications.
The work to be carried out can be roughly broken down into two main efforts: (1) the development of the atomtyping framework, including the formalism to express forcefield usage semantics, and (2) examination of case studies designed to test, validate, and refine the atomtyping framework. We note that these efforts will be executed concurrently, to provide a continual loop of development, testing, and refinement.
One of the main goals of the proposed effort is to design a domain specific language (DSL) for annotating forcefield parameters. The DSL will be used to express the chemical context in which the particular atom type is applicable. This DSL will, effectively, serve as a means to unambiguously document the forcefield. The syntax we propose will be expressive, unambiguous, and both human and machine readable.
Consider the following example of tagging the carbon
atoms in the perfluorobutane (shown in Fig. 1) with
its usage semantics to create the DSL. Atom type 791
in TINKER’s OPLS-aa parameter database [
which can be used in a chemical context where it has 3 bonded fluorines (F ), and one carbon. Similarly, atom type 792, applicable to carbon atoms that are part of a fluorocarbon backbone, would be annotated as C792 : type = C & count(bonded atoms(type = C)) = 2 & (2) count(bonded atoms(type = F )) = 2:
Notice that the above annotations are logic statements consisting of predicates over the topology: type = C evaluates to true if and only if the chemical species of the atom is carbon (here, C is a built-in type); bonded atoms() evaluates to the set of all atoms bonded to the one of interest, which can be further filtered by predicates. For instance, bonded atoms(type!=C) would evaluate to a set of all non-carbon bonded atoms. The proposed DSL will also supports functions on sets, such as count(), and common set operations such as union, intersection, difference, etc. Also, the formalism will support the existential and universal quantifiers (exists() and f or all()) to allow evaluating first-order logic statements over sets. Furthermore, the language will include support, through built-in functions, to express common molecular structures that are too verbose to express otherwise, such as, for instance, rings of a particular size.
For convenience, we will allow the annotations to reference user-defined types in the language (not just the built-in chemical species, such as C and F). The statement
C791 : type = C & count(bonded atoms(type = F )) = 3 & (3) count(bonded atoms(type = C792)) = 1 would specify that the carbon atom at the end of the fluorocarbon chain must have a C729 type neighbor, which is a carbon in the fluorocarbon backbone. This is clearly a more restrictive atom type usage specification than Eq. 1, allowing it to more specifically express the chemical context.
It is crucial that the annotation syntax we propose be future-proof and support the evolution of forcefields. Evolution can mean two things: a.) the forcefield gets extended with support for new chemical species, or b.) already supported species get more specialized. Annotating the atom types for the newly added chemical species can trivially be done incrementally. However, when an existing atom type is specialized, other existing atomtyping rules referencing the specialized one can also be affected. For instance, let us assume that we want to distinguish between C791-type fluorocarbon end groups based on what kind of carbon they are bonded to. Let us assume that to do this, we would remove the C791 atom type from the forcefield and replace it with C791A for a chemical context when the carbon neighbor is part of a fluorocarbon backbone (C791), and with C791B if it is not. Since the generic C791 type has been removed from the forcefield, all existing annotations that reference it need to be changed to reference C791A and/or C791B.
We want to avoid this, because it would make extending annotated forcefields a laborious and error-prone task, which would hinder the wide-spread acceptance of our proposed formalism, and would jeopardize the success of our efforts. To tackle this issue, the annotation language will allow multiple atom types to be handle molecules with ring structures, a global invariant can state that: f or all(type = C; !in ring()): (6) We note that as part of defining the DSL for annotating the forcefield, we will develop various “helper” tools to ensure proper syntax usage. assigned to a given atom in a molecule, but the atom type annotations will be required to explicitly express the specialization relations (i:e:, that atom type C792A overrides C792). This way, if multiple atom types are applicable to particular chemical context, it is the most specialized one that will get assigned to the given atom. The following example demonstrates a possible syntax to achieve that, by including the definition of a more generic perfluoroalkane carbon, CP F A.
CP F A : type = C &
Support for overriding annotations is important for two reasons. First, it allows for incremental development of forcefields, and second, the overridden, more general atom types can be used as wildcards in references. Consider the following annotation of a torsional term defined over four carbon atoms on a fluorocarbon backbone (bonds, and angles are annotated similarly):
C13 C13 C13 C13P F A is applicable to a series of four carbon atoms such that the first and the last one can be any kind of carbon in a fluorocarbon molecule, but the two middle atoms must be of a more specific type, C792, with exactly two carbon neighbors. This allows us to uniquely identify bonded interactions for atom-types that are of the same “atom class.” The DSL can also be extended to provide other parameters that may be required, for example, a molecular length option to unique identify instances when a specific torsion parameter should be used.
Apart from annotating atom types and various bonded
interaction types (bonds, angles, torsions) in the
forcefield, the proposed language supports global invariants,
as well. These invariants can be used to express
constraints on the applicability of the forcefield as a whole,
and are essential to prevent force field use on
unsupported topologies. For example, if the force field cannot
topology. This ensures that all referenced atom-typing mapped to Datalog, what are the performance
implirules are evaluated before those that reference them. If cations, including Datalog query execution scales with
multiple annotations evaluated to true for a given atom the topology size and the number of atom types in the
in the input topology (e:g: CP F A, C791, and C791A), the forcefield.
most specialized type (C791A) will be chosen, following Subgraph isomorphism. We expect that many (but
the @overrides relations of the annotations. Obviously, not all) of the forcefield annotations will, implicitly,
this naive approach would fail if no partial ordering describe the chemical context as a subgraph. While the
of atom type annotations would exist, i:e:, if there are subgraph isomorphism problem, in the general case, is
annotations that mutually reference each other, or if NP-complete [
Fixpoint-based method. Allowing recursion in anno- present in the overall topology [
Logic programming. Logic programming lan- mance than directly mapping such atom type annotations
guages [
An important difference between Prolog and Datalog is unique in that it provides two very distinct types of is that while Prolog is an expressive, general purpuse testing: 1) verification of the underlying rules to evallogic programming language, Datalog is not Turing- uate inconsistencies and 2) validation of the outputted complete, and mostly focuses on reasoning about data. molecular models.
Also, Datalog imposes restrictions on the the use of 1) Verification negation and recursion (Prolog does not), however, Dat- With verification, we want to answer the question: “Are alog queries are always guaranteed to terminate (while we annotating the forcefield correctly?” The fact that our in Prolog, there are no such guarantee). proposed annotation syntax can be mapped to first-order
In the proposed effort, we will investigate how force- logic statements makes it possible to “reason about” the field usage specifications and input topologies can be annotated forcefield as system of atom-typing rules, even We propose to develop a validator tool that does just this this: takes an annotated forcefield as an input, and iterates through a large number of correctly atom-typed topologies ensuring that the atom-type annotations and global invariants are never violated. If the validator finds a topology that is in contradiction with the forcefield annotations, it is the chemical scientist who needs to revisit and correct the forcefield, rather than a source code issue.
The development and testing of the atom-typer tool is
much alike that of any software. Importantly, it can be
carried out without chemical domain expertise. This is
analogous to developing and testing a database server:
the software developers are not concerned with what
data, in what schemas, will the users store in the
database, but rather focus on testing the functionality that
implements how queries are answered. In the proposed
effort, we will use state-of-the-art software testing tools,
including unit tests packaged into test suites, as well
as coverage tools to quantify the degree to which the
source code is tested. The source code of the tools will
be stored on GitHub [
Are there rules that are not decidable? Are there any
annotations that will never evaluate to true, irrespective
of the input chemical topology? Can it ever happen that
two rules may hold true at the same time, without one
overriding the other? Are there any atom-typing rules
that are in contradiction with the global invariants? If
the answer to any of the above questions is yes, it
indicates an error in the logical structure of the forcefield
annotations. We propose to verify such properties on the
system of forcefield annotations, and will provide a set
of development tools that help the forcefield developers
pinpoint these inconsistencies early in the forcefield
development process. We expect that some of the above
violations will be detectable by the Datalog interpreter
after the annotations are mapped to Datalog syntax,
while others, pertaining to ensuring boolean satisfiability,
will require us to integrate a theorem prover such as the
widely used Z3 solver from Microsoft Research [
Our proposed goal is to prove that the forcefield is complete in the logical sense, that is, if the forcefield’s annotations evaluate to “true” on a correctly atom-typed topology, then the atom-typing tool is guaranteed to compute the correct atom-typing, given the annotated forcefield, the chemical species of the atoms and their connectivity as inputs. We will strive to reach this goal, even at the cost of reducing the expressiveness of the annotation language.
Continuous integration (CI) is a software development
practice that encourages members of the development
team to integrate code into a shared repository several
times a day. On each check-in, the software is
automatically built and tested, allowing teams to detect
problems early. Commonly, CI is provided as a cloud
service. Developers set up a project with a CI service
provider (e:g:; Travis CI [
Notice that if an annotated forcefield passes verifica- software build, test, and release processes. The proposed tion (i.e., it is complete in the logical sense), we can forcefield CI service (see Fig. 2) will watch the reposvalidate it in an isolated way, without having to execute itories where the annotated forcefield files are hosted. the atom-typer tool. It is sufficient to check that the Also, it will integrate with existing online repositories forcefield’s annotation statements hold true on a set of that host correctly atom-typed molecules, which will be correctly atom-typed topologies (test cases), which will automatically downloaded and used as the “ground truth” entail, due to the completeness property, that the atom- for forcefield validation. V&V of annotated force field typer will be able to compute the correct atom-typing. files will be triggered when either a.) changes in the repository are detected b.) new correctly-typed molecules are added.
Although there exist some meticulously well maintained and “alive” forcefield repositories, that are, not surprisingly, typically specific to a particular simulator tool or chemical or biomolecular domain, cataloging forcefield development of the past decades into a coherent, unified, searchable online forcefield database would be an enormous undertaking, which is not feasible without community involvement.
The implementation of such an online database would not be technically challenging. Neither would be operating and maintaining such a service. However, convincing the developers of new forcefields to upload their parameter sets, to correctly tag them with how and in what context the values are applicable, to supply test cases, etc., would surely be a futile attempt.
It is well known it is notoriously hard to get outside users to upload their work to a repository. A novel aspect of our community building approach is that we will incentivize our users to do so by giving them free access to our continuous integration infrastructure: outside users will register their own repositories with the forcefield CI service, which will provide automatic, continuous verification, validation, and testing for their forcefields at no cost.
Whenever a new commit or pull request adds or modifies forcefield related files in the users’ registered repositories, the CI service will trigger the verification and validation workflow. Once a forcefield (or a new version of a forcefield) passes all tests, the CI service will publish it (that is, the annotated parameter set, its source URL, and the test results) to our online forcefield repository, assigning to it a permanent URL and a document object identifier (DOI) for referencing and attribution purposes.
Through the development of a new formalism for chemical context and novel atom-typing scheme, our approach unambiguously describes the appropriate usage of forcefield parameters and helps to reduce atom-typing as a source of error during model development. Developing this framework will simplify the rules needed for atomtyping, which is crucial as forcefields continue to grow, specialize, and become more complex. The machinereadable annotations of forcefield usage semantics will enable automation of tedious and error prone tasks, and will enable new application areas, ranging from automated forcefield comparison and cross-validation, to complex simulation workflows integrating multiple forcefields and simulator tools. Through offering our verification, validation, and testing infrastructure as a free-of-charge continuous integration service to the community, we believe that our approach has the potential to foster community involvement through the creation of a online forcefield repository for the annotated forcefields that tagged with DOIs for proper referencing and attribution, the associated software, and documentation of our framework.
This work is supported by the National Science Foundation under grant number ACI 1535150.