Nathan Wohlgemuth and Dan Ess, Department of Chemistry and Biochemistry
Organic and organometallic reactions are generally assumed to follow statistical mechanical models of reactivity and selectivity that correspond to transition state theory. However, in recent years there have been several organic reactions that have been shown to be controlled by post-transition state reaction dynamics. While some direct dynamics programs are available (VENUS, ProgDyn, etc.) they are generally difficult to use and have little documentation. To overcome this problem, we created a molecular dynamics software suite (called DynSuite) that interfaces with the electronic structure program Gaussian 09. We used this software to perform known examples of direct dynamics simulations for organic and organometallic reactions to prove the correctness of our software.
DynSuite, our molecular dynamics software suite, was designed by using ProgDyn, an already existing direct dynamics program, as a starting point. ProgDyn, as a program, is written in a functional style of programming which works well for small, simple programs but tends to become intractable for more complicated programs. We decided to use an object oriented programming style for DynSuite, a style which virtually every large software application project in the world now employs. During the time we spent designing the architecture of DynSuite, we consulted with the creator of ProgDyn, Dan Singleton, to get a better understanding of the software.
While ProgDyn was an invaluable resource in our work, it does have two serious flaws. The first flaw was a nearly complete lack of error checking. If anything goes wrong during the simulation, ProgDyn has no way to detect what went wrong and no way to inform the user that any problem exists. We addressed this shortcoming in DynSuite by building in a great deal of error checking and included a robust logging system to give users detailed information about the simulation as it proceeds. The second flaw was the lack of an easy to use interface for the user. To be able to use ProgDyn at all, the user must spend a significant amount of time understanding the internal details of the program. Ideally, these internal details should be of no concern to the user. To address this issue in DynSuite, we first organized DynSuite around the concept of using a single XML file to store all of the data needed for a particular direct dynamics simulation. In future work, we intend to create a sophisticated graphical user interface (GUI) that will allow users to quickly and easily modify these XML files as well as launch and analyze simulations from these XML files.
To prove the correctness of DynSuite, we first replicated the results of study that Dan Singleton did that investigated the dynamic effects of the hydroboration of propene reaction.1 After replicating that study, we moved on to simulating the radical reaction of cyclopentadiene and tetrafluoroethylene. This reaction helped us further improve the correctness of DynSuite and we anticipate publishing a paper on the results of our simulations.
Testing the overall correctness of DynSuite proved to be a formidable challenge. Because the simulations that DynSuite performs are inherently probabilistic, it is not necessarily straightforward to determine if the output of DynSuite is correct. We decided to use the behavior of ProgDyn as our benchmark of correct operation. To do this, we had to use the same set of random numbers between the two programs. By following the two programs through various points in the simulation, we could find and eliminate errors in DynSuite. This process had to be repeated for the many different combinations of input parameters that the simulation takes. This was a very time consuming task and occupied a substantial amount of our time.
One of our goals with DynSuite was to be able to provide helpful and detailed documentation along with the source code. To be able to do this, we wrote the documentation directly into the source code as comments and then utilized a program called Doxygen to parse these comments and generate both PDF documentation and HTML documentation. We have uploaded the HTML documentation to a Microsoft Azure server to allow users to access the documentation as needed. By having the documentation directly in the source code as comments, it makes updating the documentation much easier and therefore more likely to stay up to date.
Building a software program as complicated as this one (14k+ lines of c++ code alone) proved to be a substantial undertaking. However, by following software engineering best practices, we were able to create a software suite that offers key improvements over existing programs. The most valuable improvement will ultimately be ease of use. We have already moved onto creating a GUI for DynSuite that, when completed Spring of 2017, will dramatically improve the efficiency of those using the software. We also expect that users will benefit greatly from the error handling and logging capabilities of DynSuite.
1 Oyola, Y.; Singleton, D. A. Dynamics and the Failure of Transition State Theory in Alkene Hydroboration. J. Am. Chem. Soc. Journal of the American Chemical Society 2009, 3130–3131.