…Or as Bazaar just saved me the day
In bioinformatics the Good Programming Practices are always seen as a “too big solution for a too small problem”.
BioinfoBlog is not of this advise and I totally agree.
For example the use of a Version Control System is always seen as an overdue for our project (classical objection: my project is just a bunch of scripts… yeah.. sure….).
Let me try to convince you with a real life example and why today bazaar save my day (or at least a lot of time).
Scenario: I was running a custom simulation of this model available from Biomodels database when I saw that something that before was working it wasn’t anymore!
The model encodes the really complex series of biochemical reactions that permits DARPP-32 (a protein present in the spine of the Medium Spiny Neuron) to integrate different stimuli (Glutamate and Dopamine releases) and to respond accordingly.
for the brave biologist or interested scientists between you I promise I will speak about this later on….
To better understand the model and simulate different input today (ok, the simulation started yesterday night..) I was running a simulation using a stochastic simulator. The expected result would be to have different output due to the stochastic variability but still quite similar.
Bear in mind that I will show you 4 copies of the same simulation that should diverge only for the stochastic effect; this means you should expect 4 curves that will be more or less of the same shape.
In this image you can see the time courses of the molecules of DARPP-32 (D) in the not phosporilated state; there is a dramatic drop of this form of the protein because the input of Calcium activate several kinases that are going to phosphorilate DARPP-32. The input of Calcium is applied (technically is a train of Calcium) at 100s
The discrepancy between the four trajectories is too big and cannot be addressed to the stochastic variability only, but it looks like in three of the iterations there is the lack of the input (No Calcium applied at all).
So I took a look to the trajectory of Calcium to see if it was missing:
Calcium input 4 different iteration
Eureka! The Calcium is not applied in the 3 of the four iterations.
If you thinking where is bazaar and why it saved my day… don’t worry! I’m getting there… It just takes time…
So I know:
- which is the reason of the Bug
- I know that I refactored the code some time ago to have the possibilities to ran different kind of simulations and I very likely introduced the BUG
- I know the simulation was working before this point
I fired up olive and try to understand where and when I’ve changed this bit
Olive GTK screenshot
The selected revision is the one where I refactored the code and added the new Experiment class to better shape my inputs, and the one where most likely I’ve introduced the BUG.
Rewieving the changes that I made I found out that I don’t create a new list of inputs for each iterations, but only for the first one, so when the other iterations check for the input to apply, they don’t find anything!
So I fixed the BUG, and I re-run the simulation and I’ve got the right results.
4 iterations DARPP-32 BUG fixed
If I didn’t have bazaar installed or I didn’t use any VCS, I had to spend a lot of time to debug my code this morning with no clear idea where to look and what to change. More over there would be also the frustration to get something to work again when it was working before.
So if you are in bioinformatics or you like/have to program think about to use a VCS. I’m using bazaar because it’s easy, it’s distributed and it has also a really good svn-bridge-plugin, so I can push all my code to the svn of my group 😉