Difference between revisions of "Team:Exeter/Modeling"

Line 181: Line 181:
  
 
<h3>Future improvements</h3>
 
<h3>Future improvements</h3>
 +
 +
<p>trajectory on top and bottom, bugs in trajectory, </p>
  
 
<!-- This is where my buttons are -->
 
<!-- This is where my buttons are -->

Revision as of 14:58, 13 September 2015

Modelling

Introduction

Modelling is a fundamental part of our project, it allows us to not only test our system rigorously but also provide a visual output to make it easier to see what is going on. The purpose of the model is to mainly inform the lab team and improve and compliment their experimental design.

Our model is designed around a MatLab based physical simulation, contained within a microcentrifuge tube that we will use in testing. MatLab was chosen as the programming language of choice as we had all used it before and were comfortable with it.

Our model is built up from two parts:

  • A system simulation designed in MatLab, enabling a visual demonstration of the system as well as assisting in the second part.
  • Graphical output of parameter scanning developed from the MatLab simulation. This allowed us to check each input variable over a wide range of values so that we could determine the optimum experimental range of each.

We also aim to build a mathematical model to perform parameter scanning, this would then be compared with the simulation based model.

Producing a graphical and numerical output allows us both to establish the controlling factors in our experiment, and to understand the mechanisms of the system. Parameter scanning lets us inform the lab team of the optimal parameter values as well as what parameters can be left alone. By using two methods of parameter scanning we can compare these and hence improve the data given to the lab team.

Simulation

The idea for the model was conceived within the first week after choosing our project. It was based on the idea that the particles would behave in a random motion similar to that of Brownian motion.

We chose to use Matlab, as it was the only one that every member of the modelling team had previously used. This allowed us to start work on it right away as we did not need to learn a whole new computer language.

The fundamental idea was to have two types of particles on a random walk which could then interact with each other if they came close enough. These two particles would be the RNA trigger and the Toehold switch.

The aim of this would be to provide a visual output so that people could see what was going on within our physical system. So in effect we would be creating a simulation of our system. This drove the model in the beginning as we started to try and implement as many real world features as we could, to get the most accurate simulation.

The first of these features was to make something happen when the trigger and switch got close enough to bind hence forming a complex. We made them join together irreversibly, this was primitive but allowed us to forge ahead. The next feature was to make the simulation 3D. This was achieved relatively easily.

After consulting with the lab team we had even more to add to our model. The first thing that needed to be implemented was to allow the complex to break apart after being joined for a period of time. This was to fix the primitive nature of the permanent binding and more accurately reflect the mechanisms inside the system. Next a spherical area of binding was added to replace the cube previously used. This means that the trigger and switch have two spheres at either end which if overlapping, results in their binding. This simulated the spherical area of influence which we estimated to be around the trigger and switch.

A spherical area of influence was used after a discussion with Prof Peter Winlove, we asked him if it would be possible determine the actual size of the trigger and switch, he said this would not be possible. Instead he suggested that we estimate the size of the molecules and assume a sphere around it in which interactions will occur.

INSERT A BIT ABOUT THE MATHS USED FOR THE TWO INTERACTING SPHERES.

Once this was achieved the simulation acted reasonably like the real world system. To improve a lot of research was done to try and find out real world values to add into the simulation. These included particle diameters, binding distances, viscosities, temperatures, etc. After speaking to an advisor we decided to use low binding affinity tubes, allowing us to negate any binding interaction with the walls of the tube. This information was needed so we could figure out what happened to the particles at the wall of the tube containing our sample.

Now we had all the information needed we could confine it to the tube. After consulting with the lab team we chose a 1.5ml microcentrifuge tube. Initially we set up to confine it to a cylinder with the volume equal to the tube. The idea was that, by adding in a confinement element, we could simulate the interaction between the walls of the tube and the particles. Initially we just made it so if they left the tube the particles were placed at its edge. This was a basic step, with the thinking being we would add in a rebound function later.

INSERT THE MATHS ON CALCULATING IF IT HAS LEFT THE TUBE

INSERT A BIT ABOUT THE FIRST JONATHAN MEETING

After a meeting with a computer scientist at our University, we set about improving our code. The plan was to implement a new coordinate generation system, change the confinement, and finally separate into functions. The plan was first thought out on paper, we then tried to implement this.

The first thing we did was to change the coordinate generation so that it happens on every time step rather than all at once at the beginning. This means that we only need to pass two sets of coordinates between each function per time step, hence speeding up or code. After this a speed test of the code was performed and this decreased the compiling speed by around a half. Another benefit of this generation was that we could store the coordinate into an array which we could then use for many different reasons after the generation had happened. These included producing the 3D simulation and the numerical output.

Once the coordinates had been simplified splitting the code into separate functions also became a lot easier. This was due to the fact only one vector (with the coordinates of the current and previous timesteps) needed to be passed between the functions. The code was split based on the functions that they performed, such as plotting and confinement. This was a serious undertaking and took a lot longer than expected. Our Matlab skills were stretched and a lot of trial and error was needed to make the functions work as expected.

The confinement was changed so that it more accurately mimicked a microcentrifuge tube, this was achieved by altering the cylinder previously used and adding a cone to the base. The cone presented an issue as the radius will not be constant along its height, this required the radius to be calculated ad hoc.

INSERT BIT ABOUT THE CONE RADIUS MATHS

After all of the changes Jonathan suggested had been implemented a lot of debugging and optimisation occurred. This was jointly to do with our coding skills improving, our coding skills being tested, and more input from academics. We optimised loops, variables and functions; added in a cool down period and a requirement that the trigger and switch bind for at least one time step.

The benefit of all of this work was that now the code is separated into functions debugging can occur quicker, the code is simpler and more efficient, and finally it gives us the freedom to choose what output we like. We can either use the random walks to produce a visual simulation or a numerical output which when combined with parameter scanning can be a powerful tool.

Two new features were worked on in tandem, these are parameter scanning and a trajectory/collision function for the interaction of particles with the walls of the chamber.

INSERT MATHS ABOUT TRAJECTORY STUFF

changed confinement to a cylinder after discussing with lab that it would be in a well plate.

Assumptions

  • Low affinity tubes
    • The cell free kit components will not stick to the walls of the microcentrifuge tube.
    • This assumption is made as we modelled the particles as bouncing directly of off the walls of the tube.
    • These were chosen for this reason and after talking to Nick Harmor, the tubes were provided by Eppendorf.
  • Ribosome Stays Bound
    • Once the ribosome attaches after the binding site is revealed it stays bound. It was also assumed that it makes the protein once the ribosome is bound.
    • This assumption was made as a way of producing a numerical output, as it allows us to say x amount of GFP will be produced in a given time period.
    • Once bound GFP is made.
  • Rate of ribosome movement contains the rate of RNA, amino acid production, and all other translational steps.
    • This is again needed to simplify the numerical output as above.
  • Elastic collisions
    • This concerns the collisions with the walls of the container, they are assumed to be elastic to simplify the maths and hence the simulation as no loss of kinetic energy is taken into account.
  • Assume an excess of substrate
    • This allows us to assume that translational machinery is not a limiting factor in GFP production.
  • Random starting positions
    • The lab team is advised to shake the tubes before an experiment to achieve this.
  • Spherical particles
    • The individual Toehold switches and RNA triggers are assumed to have a spherical area of influence.
    • The radius of the spheres is an approximation based on the length of a base pair and the number of base pairs in the sequence.
    • This was done after discussions with Peter Winlove about whether we could measure the actual size of the particles. Unfortunately we could not do this.
  • Spherical binding
    • As the particles are assumed to be spherical in shape we needed to assume that these would interact if the two spheres overlapped each other.
  • Constant temperature
    • The experiment is assumed to be carried out at a constant temperature
  • Constant speed
    • The particles travel in the container with a constant speed, this is made as we assume there to be no effects from gravity.
  • No denaturing above a certain temperature
    • (could decrease join probability at higher temperatures to correlation with decreased proportion of toeholds in correct conformation)

References

Future improvements

trajectory on top and bottom, bugs in trajectory,

  • Contact us:
    exeterigem@gmail.com