Revision as of 23:16, 21 September 2011 by Jaap (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Desing Considerations

Because of the device-like nature of out project modeling plays a big part. Our model evolved from a simple MATLAB model to a full-blown cloudcomputing application partially out of curiosity but also part out of necessity. This page gives an overview of some of our considerations as to building Cumulus.

First of all we have tried to decide in what environment we wanted to model in. There is a lot of different software out there. Our 2009 team did a large survey on modeling packages used in iGEM [1]. Our whitebook (information from previous teams)also included several bio-modeling packages that we should look at:

SynBioSS

SynBioSS features a GUI implemented in python and can interface with most mayor other modeling frameworks such as SBML, Hy3S as NetCDF. It does not have a good visualization interface and it suggest you load your results into MATLAB for examination. SynBioSS also includes a supercomputer Message Passing Interface (MPI) implementation which is nice if you want to go all out on some sort of cluster architecture. Unfortunately SynBioSS is unstable, does not support 64 bit architectures and nobody has worked on it since 2010. Therefore it ceased to be an option for us. SynBioSS can be found at [http://synbioss.sourceforge.net/simulator/]

CellDesigner

CellDesigner is graphical simulation package that can model simple cellular mechanics. Though it looks pretty it is not very useful. While it has a superb graph and gene-network drawing options. It has relatively limited visualization options for simulations. It biggest shortcoming is that the mathematics that can be used to define the reaction speeds are rather limited. There are no options for stochastic implementations so checking the robustness of your circuit will be a tedious process.

COPASI

A rather comprehensive modeling package but without any visualization options. It offers extensive modeling and analysis support but nothing in the way of plotting functions or graphs. Although it would be nice to be able to use partial differential equations, its confinement to ODE´s is not a big issue.

MATLAB with SimBiology

SimBiology is a modeling GUI very similar to COPASI. Its added advantage is it's integration with the MATLAB environment. This means that you can use scripts, functions and other methods produced in MATLAB to extend on existing functionality. Although it looks nice on first glance, it's bugs and quirks are numerous. A horrendously broken unit system combined with a user interface that is not all that user friendly make producing something in SimBiology a challenge that might not be worth taking. SimBiology also enforces the Markov assumption: every next time-step can be calculated using only the previous time-step. This results in problems when modeling transcription and translation accurately. Although we where able to produce a workaround we would not recommend such tricks to inexperienced MATLAB users.

Verdict

Although COPASI and SimBiology seemed really nice (be sure to look at it when in doubt) we decided to go with MATLAB for our first model for the following reasons:

• Freedom of programming: Although the MATLAB programming syntax is rather cumbersome (especially when using OOP) we are sure it can produce anything we want.
• Popularity: There is a very large user base for MATLAB and plenty of support for it. Many other iGEM teams use it so it will be easy to share your findings and models.
• Great plotting and visualization option: this will allow us to see what is going on without the hassle of exporting and importing the data to other packages.
• Familiarity of the team: Not having to learn using a program from the beginning is a big advantage. Some of our members have years of experience with MATLAB and have no problem implementing anything in MATLAB.

Library

After this survey we tried building a preliminary model in MATLAB . Here we already used the modular system of interchangeable parts that is so central to Cumulus later on. The verification of such a model however would require data that was very hard to obtain. It was for that reason that we wanted a parameter optimization system that could deduct the underlying parts parameters from measurable output-data. For this we need two things: A more robust object oriented language and more computational horse power.

Move to .NET

It quickly became clear that MATLAB has some limits considering both object oriented programming functionality and large scale computing support. Both its grid-computing facilities and its framework of inheritance and function-access are seriously underdeveloped. What we needed was a full fledged object oriented language that would allow us to build a network architecture, database interface and user visualizations. We again looked at the expertise within our group and decided that it would be best to go with .NET and the Azure cloud platform. The result of this renewed effort would become the Cumulus system.