"
Team:St Andrews/project/modelling
From 2010.igem.org
(→Under the Hood) |
(→Under the Hood) |
||
| Line 8: | Line 8: | ||
Hello and welcome to the St. Andrews iGEM 2010 modelling pages. Here we present our work completed throughout the 2010/2011 summer, the methodology behind our various models, and some of the conclusions we drew from those pieces of work. | Hello and welcome to the St. Andrews iGEM 2010 modelling pages. Here we present our work completed throughout the 2010/2011 summer, the methodology behind our various models, and some of the conclusions we drew from those pieces of work. | ||
= Under the Hood = | = Under the Hood = | ||
| - | All our models are based upon a series of ordinary differential equations (ODEs) each of which have been derived from either prior research papers or our own research. These equations are solved computationally via the forth order Runge-Kutta method - the classical iterative method of approximating numerical ODEs. Seeking full control of the implementation of our model we decided against the use of mathematical packages and instead decided upon using a full fledged programming language to develop our models. Initially we decided upon GNU R, a programming language and environment for statistical computing. While R allowed for the rapid development of our initial models it was found that R lacked the fine grain control and the raw machine efficiency that we so required. A key problem that we encountered was that the majority of ODE solver libraries available for R were not in fact written in R, instead they were written in FORTRAN and C and the R component of the library meerly passed data to and from the external program. This was problematic as it did not allow us to access and modify the ODE solving algorithm which, in order to acquire the full set of data pertinent to any of or models and thus made future use of R infeasible. Instead we turned to C++, a far lower level language than R hoping for greater power of design. Being a compiled language (with a efficient compiler) C++ programs proved far faster than their R counterparts and offered a far finer degree of control. Initially we developed our own RK4 based ODE solver and put to work developing all our models as C++ programs. Output of the each of the models was processed and graphed using the gnuplot graphing utility. In line with the nature of iGEM all of the software used in development of our models was Free software | + | All our models are based upon a series of ordinary differential equations (ODEs) each of which have been derived from either prior research papers or our own research. These equations are solved computationally via the forth order Runge-Kutta method - the classical iterative method of approximating numerical ODEs. Seeking full control of the implementation of our model we decided against the use of mathematical packages and instead decided upon using a full fledged programming language to develop our models. Initially we decided upon GNU R, a programming language and environment for statistical computing. While R allowed for the rapid development of our initial models it was found that R lacked the fine grain control and the raw machine efficiency that we so required. A key problem that we encountered was that the majority of ODE solver libraries available for R were not in fact written in R, instead they were written in FORTRAN and C and the R component of the library meerly passed data to and from the external program. This was problematic as it did not allow us to access and modify the ODE solving algorithm which, in order to acquire the full set of data pertinent to any of or models and thus made future use of R infeasible. Instead we turned to C++, a far lower level language than R hoping for greater power of design. Being a compiled language (with a efficient compiler) C++ programs proved far faster than their R counterparts and offered a far finer degree of control. Initially we developed our own RK4 based ODE solver and put to work developing all our models as C++ programs. Output of the each of the models was processed and graphed using the gnuplot graphing utility. |
| - | [http://www.gnu.org/licenses/gpl.html GNU General Public License Version 3]. | + | |
| + | == What we used == | ||
| + | In line with the nature of iGEM all of the software used in development of our models was Free software. We wish to thank each of the following communities for producing such high quality software: | ||
| + | |||
| + | * [http://gcc.gnu.org/ GCC] | ||
| + | * [http://www.vim.org vim] | ||
| + | * [http://www.gnuplot.info gnuplot] | ||
| + | * [http://www.codeblocks.org/ Cide::Blocks] | ||
| + | |||
| + | |||
| + | == License == | ||
| + | All of our models are released under the [http://www.gnu.org/licenses/gpl.html GNU General Public License Version 3]. | ||
= Components = | = Components = | ||
Revision as of 13:42, 4 September 2010
Modelling
Contents |
Introduction
Hello and welcome to the St. Andrews iGEM 2010 modelling pages. Here we present our work completed throughout the 2010/2011 summer, the methodology behind our various models, and some of the conclusions we drew from those pieces of work.
Under the Hood
All our models are based upon a series of ordinary differential equations (ODEs) each of which have been derived from either prior research papers or our own research. These equations are solved computationally via the forth order Runge-Kutta method - the classical iterative method of approximating numerical ODEs. Seeking full control of the implementation of our model we decided against the use of mathematical packages and instead decided upon using a full fledged programming language to develop our models. Initially we decided upon GNU R, a programming language and environment for statistical computing. While R allowed for the rapid development of our initial models it was found that R lacked the fine grain control and the raw machine efficiency that we so required. A key problem that we encountered was that the majority of ODE solver libraries available for R were not in fact written in R, instead they were written in FORTRAN and C and the R component of the library meerly passed data to and from the external program. This was problematic as it did not allow us to access and modify the ODE solving algorithm which, in order to acquire the full set of data pertinent to any of or models and thus made future use of R infeasible. Instead we turned to C++, a far lower level language than R hoping for greater power of design. Being a compiled language (with a efficient compiler) C++ programs proved far faster than their R counterparts and offered a far finer degree of control. Initially we developed our own RK4 based ODE solver and put to work developing all our models as C++ programs. Output of the each of the models was processed and graphed using the gnuplot graphing utility.
What we used
In line with the nature of iGEM all of the software used in development of our models was Free software. We wish to thank each of the following communities for producing such high quality software:
- [http://gcc.gnu.org/ GCC]
- [http://www.vim.org vim]
- [http://www.gnuplot.info gnuplot]
- [http://www.codeblocks.org/ Cide::Blocks]
License
All of our models are released under the [http://www.gnu.org/licenses/gpl.html GNU General Public License Version 3].
Components
Our project can be divided into two main components: the engineering of a bistable switch into the LuxR quorum sensing system, and the integration of CqsA (the biosynthetic enzyme present in the cholera system) into the LuxR circuit. The aim of the modeling side of the project was to treat these two tasks independently and on their completion construct a combined model. However, this initial aim was proved to be almost impossible due to the lack of rate constants for the cholera system, which has only been understood in its full complexity relatively recently [1]. In order to reach a compromise, we have built a number of qualitatively accurate models for the bistable LuxR system, and outlined a framework of differential equations for the cholera system which are correct at the time of writing, and which requires more rate constants to be of further use. The work done on the bistable switch included an investigation into why exactly such a configuration of genes exhibits hysteretic behavior, and what parameters are of importance in determining the “level” of bistability of the system.
Results
To be determined...
