Create a python version of the toolbox

[murrayrm]

The current toolbox is a frontend for the MATLAB SimBiology toolbox. It might be useful to create a Python version of the toolbox that could serve as a front end for some similar Python SBML-compatible simulation platform. We could either "port" the current code or completely start from scratch.

[gatctg]

For the model I'm helping develop, we're thinking of organizing modules based on function - i.e. a user can select various submodules to add to the in vitro system like transcription, translation, etc and using that selection to inform which ODEs (or another modeling technique) we put into the model for a given reaction. What do you think of fitting the current ODEs of the TXTL model within this framework (alongside relevant parameters)? Essentially same code, but organized differently.

So far, I only have a simple transcription module that I'm modeling and trying to ground in experiments. At this point, I'm focused on making submodules that can predict experimental data, so I haven't had a chance to start implementing the framework I mentioned above. That code is in engineering->modeling->puremodel. Be warned, it is super simplistic at this point!

[murrayrm]

Organizing around function could definitely work and I agree that it would be useful to "enable" certain functions (transcription, translation, phosphorylation, energy regeneration, etc) depending on what you are trying to understand.

On relatively easy possibility would be to create a set of functions (or options to functions) that are used to describe what core mechanisms that you want. So you might say, for example:

import txtl

tube1 = txtl.setup({"tx", "tl", "RNA degradation"})        % Definite functions to implement
tube2 = txtl.newtube('control')
dna_control = txtl.add_dna(tube2, "ptet-bcd1-deGFP", 2)
model = txtl.combine({tube1, tube2})

Not sure if this is what you are thinking or not. I do think it is useful to first define the user interface and toss that around a bit, to get something that seems to be the right balance between detail and abstraction.

[vipulsinghal02]

@murrayrm @gatctg

I agree with the point on creating a small prototype, and to use that as a discussion platform. Alec, can you point me to where this engineering folder is so I might be able to browse it? [Edit Aug 1, 2017 5 pm: I found it!, thanks!]

Also, here is one possible train of thought, let me know what you think. Right now functions kick in depending on what parts are used (for example tetR repression system reactions appear when components from that system are present), while other 'core' functions are always present. I think we probably want the part specific capabilities to always just kick in when any part is put in. The 'core' functionalities could be put in the way Richard just mentioned. So I may choose to have TX and TL and dilution, but no RNA deg, for example. And composing different functional modules could be a way to model different environments (Eg.: cell = tx + tl + rna deg + protein deg + dilution; while pure = tx + tl) This method is much more flexible than the other way we might do things, which is have a cell mode, a pure mode, a txtl vesicle mode, a microfluidic device mode, etc, where the functional components are predefined. I think its worth discussing the pros and cons of the predefined modes vs the composable functions methods. Of course, no reason why we can't do composable functional modules, and then just have a few default modes just made of of these modules that come with the toolbox, but the user is free to add or remove any other modules.

[murrayrm]

I like the idea of being able to choose different functional modules to get different model environments. Perhaps commands like:

txtl.setup({'cell'})               % turn on mechanisms for cells
txtl.setup({'pure'})             % turn on mechanisms for pure express
txtl.setup({'tx', 'tl', 'RNA degratation'})          % specify individual mechanisms to use

The the MATLAB version, the txtl_setup command could set some flags that we use to decide what reactions to include when we specify DNA sequences, etc.

[vipulsinghal02]

We can use Anandh's python package (BIOSCRAPE) as a replacement for MATLAB Simbiology. Let's discuss this during the meeting on Friday, Aug 4, 2017.
@ananswam

[murrayrm]

Looks like only the compiled code for bioscrape is available right now. I left an issue to chase this down. My preference would be to make use of a fully open source simulator. Two other possibilities to consider are Copasi and libsbmlsim, both of which have Python bindings available.

[ananswam]

Okay, I finally figured out how to respond in the proper location.

@murrayrm: Cython source files are .pyx and .pxd. There are no .py files in BioSCRAPE (because pure Python is slow :).

Advantages of bioscrape:

• faster than basically everything else (including SimBiology by 5x or so)
• can handle more or less arbitrary reaction rates (such as Hill functions, products of Hill functions, things with exponential/log, functions that depend on time, etc.) at "near C speed"
• can quickly simulate entire lineages of cells <-- probably not useful at all for an in vitro toolbox
• built-in MCMC for parameter inference

Disadvantages of bioscrape:

• Not compatible with reading in a model from SBML (yet). I need to add this functionality in, something that I will do after I get my thesis in (so early Sep), but can probably get it done sooner if it's time sensitive.
• Not as well tested on multiple systems, python versions, etc. Multiple people have tested and verified it on Windows 10, Mac OS X, and Linux using Anaconda 3. Python 3 is required. It will not work with Python 2.
• Will likely have worse documentation than other more mature packages (even after I polish it up). But @vipulsinghal02 @WilliamIX or I can help out directly.
• Python's odeint and ode solver (BDF method) struggle on super stiff systems, where MATLAB's ode15s tends to handle these systems very well.
  -- This will be a limitation of any software that does not use MATLAB. I've tried many ODE solvers and I've never seen anything approaching the performance of ode15s. Stiff systems are something you will almost certainly run into when doing parameter estimation, because you will be independently varying the parameters across multiple orders of magnitude.

[murrayrm]

Sorry for the confusion. When I have used cython in the past, I have used it to convert existing python code, rather than writing .pyx and .pyd files.

[gatctg]

Hi all, sorry for not being very active on this topic. I'm happy to help if this is a priority and there is something I am able to help out with. Otherwise, I will probably focus my attention elsewhere.

[murrayrm]

I wouldn't say it is a priority. I think we mainly want to find ways to share effort if possible. Are you planning to do something in python related to modeling of cell-free? If so, how can we integrate?

[gatctg]

I will not be doing anything with python and cell-free in the near future due to time constraints, but would like to revisit it. When I do, I will be sure to let you know. Thanks!