"
Team:Groningen/modeling cumulus2
From 2011.igem.org
| (3 intermediate revisions not shown) | |||
| Line 1: | Line 1: | ||
{{HeaderGroningen2011}} | {{HeaderGroningen2011}} | ||
=Cumulus 2.0= | =Cumulus 2.0= | ||
| - | No piece of software is ever truly finished. This of course hold double for one that was produced under the time | + | No piece of software is ever truly finished. This of course hold double for one that was produced under the time constraints posed by a competition such as iGEM. Below is a list of features that we would like to implement in a future version of Cumulus. |
==More modelling components== | ==More modelling components== | ||
| - | There are currently 15 different modelling components implemented in the cumulus system. While this is certainly enough to simulate a whole range of genetic circuits, it is not nearly enough to simulate | + | There are currently 15 different modelling components implemented in the cumulus system. While this is certainly enough to simulate a whole range of genetic circuits, it is not nearly enough to simulate the whole of the parts library. We would like to add more modelling components in order to give users a headstart in modeling their systems. |
==Dynamic Modelling== | ==Dynamic Modelling== | ||
| - | Our generic modeling approach allows for the construction of a model in a matter of minutes(or hours if it is very complicated). Its main disadvantage it that they need to be programmed directly into the code. A little more programming here could allow the components to be | + | Our generic modeling approach allows for the construction of a model in a matter of minutes(or hours if it is very complicated). Its main disadvantage it that they need to be programmed directly into the code. A little more programming here could allow the components to be generated completely dynamically. This would allow us to store them in a database and have users exchange them without recompiling their software. |
==Connection to the parts registry== | ==Connection to the parts registry== | ||
| - | + | Dynamic modelling components are only the beginning. For better sharing of modelling components Cumulus needs to be connected to and actively extending the parts library. This would allow users to compare their models for a single part and inspire each other with new designs. It would also allow Cumulus to run comparative analysis and find out how different models for the same biobrick part hold out in different experiments. | |
==Cellular mechanics== | ==Cellular mechanics== | ||
| + | Currently cellular mechanics such as growth rate and ribosome or polymerase concentrations are not included in our models. Adding these would greatly improve our modeling accuracy. | ||
| - | == | + | ==Multicellular models== |
| - | Although we only use single cell models we explicitly made abstraction layer between the cell level and the level of the whole model in cumulus. This will make it simple for us to create support for multicellular models, including communication | + | Although we only use single cell models we explicitly made abstraction layer between the cell level and the level of the whole model in cumulus. This will make it simple for us to create support for multicellular models, including communication and heterogeneous populations. |
| - | == | + | ==Stochastic models== |
| - | Noise is currently not modeled in cumulus even though it is a big factor in genetic circuits. Our vision is that we could best model noise by having the model generate | + | Noise is currently not modeled in cumulus even though it is a big factor in genetic circuits. Our vision is that we could best model noise by having the model generate multiple states from every single state and merging states that are similar. This would allow us to compute not only single states but entire state distributions. |
{{FooterGroningen2011}} | {{FooterGroningen2011}} | ||
Latest revision as of 23:10, 21 September 2011
Cumulus 2.0
No piece of software is ever truly finished. This of course hold double for one that was produced under the time constraints posed by a competition such as iGEM. Below is a list of features that we would like to implement in a future version of Cumulus.
More modelling components
There are currently 15 different modelling components implemented in the cumulus system. While this is certainly enough to simulate a whole range of genetic circuits, it is not nearly enough to simulate the whole of the parts library. We would like to add more modelling components in order to give users a headstart in modeling their systems.
Dynamic Modelling
Our generic modeling approach allows for the construction of a model in a matter of minutes(or hours if it is very complicated). Its main disadvantage it that they need to be programmed directly into the code. A little more programming here could allow the components to be generated completely dynamically. This would allow us to store them in a database and have users exchange them without recompiling their software.
Connection to the parts registry
Dynamic modelling components are only the beginning. For better sharing of modelling components Cumulus needs to be connected to and actively extending the parts library. This would allow users to compare their models for a single part and inspire each other with new designs. It would also allow Cumulus to run comparative analysis and find out how different models for the same biobrick part hold out in different experiments.
Cellular mechanics
Currently cellular mechanics such as growth rate and ribosome or polymerase concentrations are not included in our models. Adding these would greatly improve our modeling accuracy.
Multicellular models
Although we only use single cell models we explicitly made abstraction layer between the cell level and the level of the whole model in cumulus. This will make it simple for us to create support for multicellular models, including communication and heterogeneous populations.
Stochastic models
Noise is currently not modeled in cumulus even though it is a big factor in genetic circuits. Our vision is that we could best model noise by having the model generate multiple states from every single state and merging states that are similar. This would allow us to compute not only single states but entire state distributions.
