I’m very excited to announce the public release of CoNtRol, a web application designed to carry out mathematical analysis of chemical reaction networks. A formal introduction has been accepted for publication in Bioinformatics, and technical documentation is available on the reaction networks wiki. In this article I want to talk a bit about the design philosophy behind CoNtRol.
AimsFirst up, in case you were wondering about the weird capitalisation, the name “CoNtRol” is an anagram of “CRN tool”. When designing CoNtRol, we had two complementary design purposes. The first was to make it easy for mathematicians, chemical engineers and biochemists to computationally analyse the possible behaviour of chemical reaction networks, without the need to do anything too technical (such as compiling/installing multiple programs), or the need to carry out any complicated calculations by hand. The second design purpose was to make it relatively straightforward for developers to add new tests into CoNtRol in future. Chemical reaction network theory is an active research area, and new results are frequently discovered and published.
User interfaceYou can judge the results by taking a look at the reference implementation of CoNtRol at http://reaction-networks.net/control/. We’ve tried to keep the interface uncluttered, while still allowing users access to more advanced features such as batch processing and debugging output if needed. We used responsive design to adapt CoNtRol for small screens, facilitating its use on smartphones, tablets and projectors. This should make it easier to try out ideas and show results at workshops and conferences. As well as the more heavy-duty mathematical analysis tools, CoNtRol also includes a number of helper features to automatically generate various bits of LaTeX markup, which we hope will prove useful to researchers writing papers about chemical reaction networks. That’s the front end. Now I’m going to talk about the design philosophy for the back end, and how it relates to our second aim of extensibility.
Programming language choicesIt was clear from the start that writing all components of CoNtRol in one single language wasn’t going to be possible. The design team (Murad Banaji, Anca Marginean, Casian Pantea and I) all prefer different programming languages. Moreover, we hope that other researchers will implement new tests and contribute them to CoNtRol, and allowing as much freedom as possible in the choice of language will undoubtedly help on that front. To that end, we settled on using standards compliant XHTML, CSS and Ajax for the interface, implemented using PHP and jQuery, with each individual test being a standalone executable written in the developer’s language of choice and executed server-side. While this structure is nowhere near as elegant as, say, a monolithic Java or Python application, it does lend itself much more easily to a division of labour between developers with disparate skills. Running the framework server-side as a web application also makes it accessible to users on all major platforms without the need to compile or install any libraries or programs. All that's required is a web browser and (optionally, to generate DSR graphs) Java. Anca wrote the DSR graph component using Java Web Start, which is executed client-side. It automatically generates a visual representation of the DSR graph of a CRN, which the user can fine tune by dragging vertices around, and then export to TikZ LaTeX markup. Murad wrote the “general analysis” test in C. Casian originally wrote the DSR test for injectivity in MATLAB, but later translated it to GNU Octave to avoid dependency on proprietary software. CoNtRol supports tests written for proprietary tools such as MATLAB and Mathematica, but we made a conscious decision to avoid them in our open source reference release of CoNtRol. The reference implementation includes an example PHP script called
dummy, which is disabled by default, to help demonstrate how to write a new test.
How tests are runWhen a user visits CoNtRol in their browser, the web server starts a session for them, storing information about the CRN as they type it. When the “Analyse CRN” button is pressed, the server saves the CRN to a temporary location in a variety of file formats, which are documented on the CoNtRol page of the reaction-networks.net wiki. It then checks which tests are enabled and which file format they prefer, and then executes each one in turn, storing the results in the session. Each test is called via the command line as follows:
./executable_name file_nameFor example, Casian’s DSR test is called via an executable POSIX shell script called
dsrand takes file input in a plain text format that describes the net stoichiometry matrix and the Jacobian matrix of the reaction rate function, which we call “stoichiometry+V”. Hence the DSR test is invoked:
./dsr /temporary/path/random_string.s+vAjax callbacks are used to determine when each test is complete, or to kill a test when it has been processing for too long. Once all tests are complete, the user is redirected to the results page, which includes the option of emailing the results to the user. Once results have been generated, they are stored in the session until the user closes their browser or chooses to analyse another CRN. The batch processing mode works similarly, but runs entirely offline via a cron job. Consequently there is no issue with PHP timeouts, and so Ajax is not required in order to keep track of when each test finishes. Results are stored in a text file on the server and the user is sent a link to allow them to download the results once processing is complete. Originally the full result output was emailed directly to the user, but for large batches this runs the risk of hitting email attachment size limits and mail filter policies blocking zip files.