Difference between revisions of "Team:Exeter/Collaborations"

 
(58 intermediate revisions by 4 users not shown)
Line 426: Line 426:
 
}
 
}
 
#title{
 
#title{
font-size:150%;
+
font-size:260%;
 +
}
 +
.banner_link{
 +
font-size:22px;
 +
}
 +
.div_banner{
 +
margin-top:20px;
 
}
 
}
 
/*Makes side pictures on banner invisible on small screens*/
 
/*Makes side pictures on banner invisible on small screens*/
Line 486: Line 492:
 
@media (max-width: 767px){
 
@media (max-width: 767px){
 
.div_vl.backgroundimage{
 
.div_vl.backgroundimage{
height:37vh;
+
height:67vh;
 
background-size: auto 200%;
 
background-size: auto 200%;
 
}
 
}
Line 511: Line 517:
 
.graph_box{
 
.graph_box{
 
max-width:90%;
 
max-width:90%;
}
 
}
 
@media (max-width: 920px){
 
#links_drop{
 
margin-left:0;
 
padding-top:9px;
 
margin-top:-4px;
 
font-size:20px;
 
 
}
 
}
 
}
 
}
Line 528: Line 526:
 
padding:0.06vw 0 0 0;
 
padding:0.06vw 0 0 0;
 
line-height:0px;
 
line-height:0px;
 +
}
 +
@media (max-width: 920px){
 +
#links_drop{
 +
margin-left:0;
 +
padding-top:9px;
 +
margin-top:-4px;
 +
font-size:20px;
 +
}
 
}
 
}
 
button.dropdown-toggle{
 
button.dropdown-toggle{
Line 536: Line 542:
 
padding-top:5px;
 
padding-top:5px;
 
}
 
}
 +
}
 +
#links_drop:hover span{
 +
color:#339499;
 
}
 
}
 
</style>
 
</style>
Line 679: Line 688:
 
 
 
<!--Give span class "oneline" or "twoline" depending on how llong the section text is-->
 
<!--Give span class "oneline" or "twoline" depending on how llong the section text is-->
<a href="#section_1" class="banner_link col-xs-6 col-sm-3"><span class="oneline">Measurement</span></a>
+
<a href="#section_1" class="banner_link col-xs-6 col-sm-2"><span class="oneline">Newcastle</span></a>
<a href="#section_2" class="banner_link col-xs-6 col-sm-3"><span class="oneline">Software</span></a>
+
<a href="#section_2" class="banner_link col-xs-6 col-sm-2"><span class="oneline">Purdue</span></a>
<a href="#section_3" class="banner_link col-xs-6 col-sm-3"><span class="oneline">Parts</span></a>
+
<a href="#section_3" class="banner_link col-xs-6 col-sm-2"><span class="oneline">Glasgow</span></a>
<a href="#section_4" class="banner_link col-xs-6 col-sm-3"><span class="twoline">Skype and<br /> Meet-ups</span></a>
+
<a href="#section_4" class="banner_link col-xs-6 col-sm-2"><span class="oneline">Edinburgh</span></a>
</div>
+
<a href="#section_5" class="banner_link col-xs-6 col-sm-2"><span class="oneline">Stanford&nbsp;Brown</span></a>
 +
</div>
 
<!--Left picture (the teal line on left)-->
 
<!--Left picture (the teal line on left)-->
 
<div class="col-sm-2 subdiv_banner right">
 
<div class="col-sm-2 subdiv_banner right">
Line 689: Line 699:
 
</div>
 
</div>
 
</div>
 
</div>
 +
 
<div>
 
<div>
 
<a id="Section_link" href="#section_1" style="display:block;margin:34vh auto 0 auto;width:14px;"><span style="color:#47BCC2;font-size: 25px;" class="glyphicon glyphicon-menu-down" aria-hidden="true"></span></a>
 
<a id="Section_link" href="#section_1" style="display:block;margin:34vh auto 0 auto;width:14px;"><span style="color:#47BCC2;font-size: 25px;" class="glyphicon glyphicon-menu-down" aria-hidden="true"></span></a>
Line 694: Line 705:
 
</div>
 
</div>
  
<div class="col-xs-12 div_content">
+
 
 +
<div class="col-xs-12 div_content">
 
<div id="section_1" class="link_fix"></div>
 
<div id="section_1" class="link_fix"></div>
 
<div id="contentTitle">
 
<div id="contentTitle">
Line 701: Line 713:
 
   
 
   
  
<p id="pp">This year we have been working alongside iGEM teams from across the globe.
+
<h3 style="text-align:center">The thermal conductivity of growth media.</h3>
We have been working closely with teams from Newcastle, Glasgow and Purdue to help each other improve our projects
+
from both in and outside the lab.</p>
+
+
<img src="https://static.igem.org/mediawiki/2016/8/88/T--Exeter--Home_collab_cond.jpg" style="float:right; width:40vw; height:60vh;">
+
  
<p id="pp">Part of the Newcastle iGEM team’s project this year
+
<p id = "pp"> <a href="https://2016.igem.org/Team:Newcastle">Newcastle's 2016 iGEM project</a> looks at the creation of biological electronic components, and as part of their modelling they needed to know the thermal conductivity of different growth media. With a strong team of physicists on board the Exeter team, they came to us for help. With support from our biophysicist supervisor <a href="http://emps.exeter.ac.uk/physics-astronomy/staff/rse204">Ryan Edginton</a>, we built an experimental setup (Fig. 1a) that made use of the transient hot wire method (Healy <i>et al</i> 1976).</p>
involved an experiment centred around the creation of biological electronic
+
components. Newcastle asked our team if we could help them out by finding the  
+
thermal conductivity of different growth media. With the help of our biophysicist
+
supervisor Ryan Edgington, we came up with a plan to measure the conductivity.</p>
+
+
  
<p id="pp">Using the apparatus we had available, we discovered that the thermal conductivity of LB and M9 broth to be roughly
 
the same as water. The conductivity of water at room temperature is about 598.4 $\frac{mW}{Km}\text{ }$(mili
 
watt per metre kelvin).We found the conductivity of LB and M9 to be (605 $\pm$ 20) $\frac{mW}{Km}\text{ }$ and (570 $\pm$ 30) $\frac{mW}{Km}\text{ }$ respectively
 
You can read more about our method <a href="https://2016.igem.org/Team:Exeter/Team/collab">here</a>.</p>
 
</p>
 
  
 +
                <p id="pp">A 0.65m insulated copper wire (cross-sectional area, 0.05m<sup>2</sup>) was passed through the centre of a 50mL falcon tube containing the liquid medium to be measured, suspended in a water bath (Fig. 1b). Three thermocouples (Pico Technology TC-08) were attached, one to the wire in contact with the insulation using blue tack, one suspended in the liquid medium 5mm from the wire, and one in the water bath. Power was supplied to the wire at 5A, 1.8V for 600s, generating a small temperature increase of approximately 2&deg;C above room temperature (23 &plusmn; 1&deg;C) to avoid convection effects. Our experimental setup was calibrated to the thermal conductivity of <a href="http://www2.bren.ucsb.edu/~dturney/WebResources_13/WaterSteamIceProperties/PropOfWaterFrom0to100Celcius.pdf">water</a> at 20&deg;C, 598.4 $\frac{mW}{Km}\text{ }$. Measurements of two growth media, liquid broth (LB) and M9 were repeated at least in quintuple.</p>
 +
 +
<div class="col-xs-12" style="width:100%;position:relative;margin:auto;padding:0;">
 +
<div class="graph_box col-xs-12">
 +
<img src="https://static.igem.org/mediawiki/2016/e/e8/T--Exeter--Template_Colab_setup.jpg">
 +
<span>Figure 1a - experimental setup of the transient hot wire method.</span>
 +
</div>
 +
<div class="graph_box col-xs-12">
 +
<img src="https://static.igem.org/mediawiki/2016/2/23/T--Exeter--Colab_2.jpg">
 +
<span>Figure 1b - arrangement of thermocouples within the falcon tube measuring thermal conductivity using the transient hot-wire method.</span>
 +
</div>
 +
</div> 
  
 +
 +
 +
               
 +
<div class="col-xs-12" style="width:100%;position:relative;margin:auto;padding:0;">
 +
<div class="graph_box col-xs-6">
 +
<img src="https://static.igem.org/mediawiki/2016/4/40/Thermal_conductivity_rep_plot_EXE2016.png">
 +
<span>Figure 2 - representative plots of temperature against natural log of time for water, liquid broth and M9 media. A fit was applied from the point where the relationship becomes linear to extract the thermal conductivities.</span>
 +
</div>
 +
<div class="col-xs-6">
 +
<p id="pp">Nagasaka and Nagashima noted that wire insulation has negligible impact on the measurement of the
 +
thermal conductivity of saline solutions (Nagasaka and Nagashima 1981) and thus can be described by the equation:
 +
$$ \lambda = \frac{Q}{4\pi\Delta T}\ \ln{(t)}$$ where $Q$ is the power per unit length of the wire,
 +
$Q = \frac{(I \times V)}{Length}$, and $\Delta T$ is the change in temperature over time $t$.
 +
</p>
 +
 +
<br />
 +
            </div>
 +
</div>
 +
 +
  <p id="pp">We found the thermal conductivity of LB and M9 to be similar to that of water,
 +
  at 605 $\pm$ 20 $\frac{mW}{Km}\text{ }$ and 570 $\pm$ 30 $\frac{mW}{Km}\text{ }$ respectively.
 +
  A linear fit of a $T$ vs. $ln(t)$ plot following only the reading from the liquid medium thermocouple
 +
will yield the conductivity (Fig. 2).</p>
 +
 +
 +
 +
<h5 style="padding-top:15px;"><u>References</u></h5>
 +
<ol style="font-size:100%;font-weight:600;">
 +
<li>Healy, J.J, de Groot, J.J and Kestin, J, The Theory of the Transient Hot-Wire Method for
 +
Measuring Thermal Conductivity,<i>Physica</i> <b>82C</b>: 392-408 (1976)
 +
<li>Nagasaka Y, Nagashima A. Absolute measurement of the thermal conductivity of electrically
 +
conducting liquids by the transient hot-wire method. Journal of Physics E: Scientific Instruments. 1981 Dec;14(12):1435–40.</li>
 +
</ol>
  
 
<div>
 
<div>
 
<a id="Section_link" href="#section_2" style="display:block;margin:20px auto 0 auto;width:14px;"><span style="color:#47BCC2;font-size: 25px;" class="glyphicon glyphicon-menu-down" aria-hidden="true"></span></a>
 
<a id="Section_link" href="#section_2" style="display:block;margin:20px auto 0 auto;width:14px;"><span style="color:#47BCC2;font-size: 25px;" class="glyphicon glyphicon-menu-down" aria-hidden="true"></span></a>
 
</div>
 
</div>
</div>
+
</div>
 
<div class="col-xs-12 div_content">
 
<div class="col-xs-12 div_content">
 
<div id="section_2" class="link_fix"></div>
 
<div id="section_2" class="link_fix"></div>
 
<div id="contentTitle">
 
<div id="contentTitle">
Software </div>
+
Software: Purdue </div>
<div>
+
<h3>Purdue Collaboration</h3>
+
  
<p id="pp">Our team helped Purdue with this by logging data for the 260
+
<p id="pp">The Purdue team, for part of their human practices, aimed to create a user friendly database of past iGEM projects, making it easier for future iGEM teams to search through relevant projects and develop their own ideas. Through a series of Skype calls, we were able to set up a collaboration between our two teams. We would be writing summaries for Purdue’s database, and in return, Purdue would run a continuous culture of a kill switch and send us the resulting data.</p>
iGEM teams of 2015 and critiquing ease of use and effectiveness of the database. For each team
+
we documented a summary of what their project was about, their track, number of team members, chassis,
+
research benchmarks, finished parts, the presence or absence of kill switches, medals and any awards
+
and nominations. We tagged the teams summaries with keywords to make finding a project much easier.</p>  
+
  
<p id="pp">We gave Purdue feedback on the design, layout and how
+
<p id="pp">Our team helped Purdue with this by logging data for the 46 iGEM projects, and critiquing ease of use and effectiveness of the database. Purdue told us we were instrumental in getting up the 2015 section of their database due to our contributions to writing up the project summaries.</p>
easy this database was to use to help them improve on what they had done so far.</p>
+
 
<br />
+
<p id="pp">For each team we produced a description of what their project was about (including anything that was particularly notable about the project), the project track, the number of team members, the chassis used (if relevant), any research benchmarks, a list of submitted parts with part numbers, descriptions and links, the medal achieved, and any awards and nominations. Each project was tagged with all relevant keywords, in line with Purdue’s aim of creating a user-friendly, searchable database.</p>
<h3>Edinburgh Collaboration</h3>
+
 
<h6>Optimising methods of data mutation detection in BabbleBlocks</h6>
+
<p id="pp">Purdue conducted a continuous culture of a kill switch that the 2015 Purdue team created but never submitted, and sent us the results of their experiment to give us a broader view of the reliability of kill switches, beyond our current scope of KillerRed and KillerOrange.</p>
<p id="pp">
+
 
Storing information on DNA offers many advantages over current methods, however mutations
+
<p id="pp">They followed a continuous culture protocol written by Dan, in which they took the OD of the continuous culture every morning and evening, adding a new flask to return the OD to 0.05 each time to continue the culture. For each day of week 1, and every other day for the weeks following that, they would prepare a glycerol stock of a sample of the culture, then test it in an appropriate way for their kill switch to test if it was still functional, and to what degree it was still functioning. Purdue said once they had substituted out LB broth for yeast YPD media, the protocol was straightforward and easy to follow.</p>
need to be carefully monitored to ensure incorrect data is not read as a false positive.
+
 
Currently for information stored on a BabbleBrick a ‘CheckSum’ is calculated by taking the  
+
 
sum of the values on each base of DNA. If the checksum of a BabbleBlock has changed between
+
the time of writing and reading, the data is considered to be corrupt.
+
</p>
+
<p id="pp">
+
<span class="equation">$C = \sum^{bp}_{n=1} bp_n$</span><br />
+
<span class="equation_key">
+
$C$: Frequency of checksum<br />
+
$n$: The integer address of base pair<br />
+
$bp$: Amount of base pairs (5 times the number of BabbleBricks)<br />
+
$bp_n$: The value of the $n^{th}$ base pair
+
</span>
+
</p>
+
<div class="col-xs-12" style="width:100%;position:relative;margin:auto;padding:0;">
+
<div class="graph_box col-xs-12">
+
<img src="https://static.igem.org/mediawiki/2016/4/48/T--Exeter--Collaboration_Edinb_1.png">
+
<span>Fig. 1. The frequency of all checksums in a babbleBlock system containing two BabbleBricks.</span>
+
</div>
+
<div class="graph_box col-xs-12">
+
<img src="https://static.igem.org/mediawiki/2016/0/0b/T--Exeter--Collaboration_Edinb_2.png">
+
<span>Fig. 2. The frequency of all checksums in a babbleBlock system containing three BabbleBricks.</span>
+
</div>
+
</div>
+
<p id="pp">
+
Currently a checksum utilizes only a small percentage of the values that can be stored.
+
A BabbleBrick contains 5 base 4 digits meaning that 4$^{\text{5}B}$ unique bits of
+
information share one of 15$B$ checksums where $B$ is the amount of BabbleBricks in one
+
BabbleBlock. This data has been plotted for BabbleBlocks containing 2 and 3 BabbleBricks
+
in Fig.1 and Fig.2 respectively. Assuming that between the time of writing and reading
+
any number of mutations can occur, the maximum probability of a mutation event resulting
+
in the same checksum can be calculated by comparing the frequency of one checksum to the
+
total frequency of unique bits of information.
+
</p>
+
<p id="pp">
+
<span class="equation">$P_C = \big(\frac{C_{max}}{F}) \approx \big(\frac{1.2 \times 10^5}{4^{10}}) = 11$% in a 2 BabbleBrick system</span><br />
+
<span class="equation">$\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\approx \big(\frac{10^8}{4^{15}}) = 9$% in a 3 BabbleBrick system</span>
+
<span class="equation_key">
+
$P_C$: Maximum probability of the same checksum occuring after any number of mutations<br />
+
$C_{max}$: Frequency of most common checksum<br />
+
$F$: Frequency of possible unique bits of information
+
</span>
+
</p>
+
<p id="pp">
+
Therefore, it can be predicted that for an average sentence containing 9 words the maximum
+
probability of the same checksum occurring will be of the magnitude of 1%. The probability
+
should decrease marginally when adding BabbleBricks due to the slightly increased range of
+
checksums that become available. This value can be optimized by altering the method of the
+
checksum to utilize a greater range of values and to spread out the frequency more evenly as
+
to reduce the maximum probability of the same checksum occurring.
+
</p>
+
<p id="pp">
+
Currently one BabbleBlock has 4 BabbleBricks dedicated to storing the checksum, giving a maximum
+
10$^4$ possible values. The first step in determining a ‘CheckMethod’ is to ensure that all checksums
+
for a suitable amount of BabbleBricks can be stored without going over 10$^4$. It is also important
+
to not use operators that will result in negative numbers or decimals, therefore limiting the  
+
possible checksum values to integers up to but not including 10$^4$, this rules out operators such
+
as subtract and divide. For this example, a suitable number of words in a sentence and therefore
+
BabbleBricks in a BabbleBlock shall be 20. All simulations will be carried out on 3 BabbleBrick
+
systems due to computing limitations.
+
</p>
+
<p id="pp">
+
Checksums are non-directional, for example a BabbleBrick of bases [2,2,2,2,2] would have the
+
same checksum as [2,1,3,2,2].  To alter this a checkmethod will incorporate the position
+
of the base in to the calculation. At each point the digit is multiplied by its position
+
in the BabbleBlock, where the first BabbleBrick has digit positions 1 to 5 and the last
+
BabbleBrick (20$^{th}$) has positions 96 to 100. A scaler $\alpha$ has been included to
+
increase the range of results. To ensure multiplications don’t result in a null result
+
the value of each base had a value of 1 added to it. The first checkemethod of one
+
BabbleBlock can be defined as:
+
</p>
+
<p id="pp">
+
<span class="equation">$M_1 = \sum_{n=1}^{bp}(bp_n + 1) . \alpha . bp$</span>
+
<span class="equation_key">
+
$M_1$: Frequency of CheckMethod 1<br />
+
$\alpha$: Scaler ($\alpha = 5$ in this example)
+
</span>
+
</p>
+
<div class="col-xs-12" style="width:100%;position:relative;margin:auto;padding:0;">
+
<div class="graph_box col-xs-12">
+
<img src="https://static.igem.org/mediawiki/2016/4/4c/T--Exeter--Collaboration_Edinb_3.png">
+
<span>Fig. 3. The frequency of checkmethod 1 for all possible bits of information in a babbleBlock system containing two BabbleBricks.</span>
+
</div>
+
<div class="graph_box col-xs-12">
+
<img src="https://static.igem.org/mediawiki/2016/d/d7/T--Exeter--Collaboration_Edinb_4.png">
+
<span>Fig. 4. The frequency of checkmethod 1 for all possible bits of information in a babbleBlock system containing three BabbleBricks.</span>
+
</div>
+
</div>
+
<p id="pp">
+
This method results in Fig.3 and Fig.4 for a 2 and 3 BabbleBlock system respectively,  
+
which shows a large improvement over the original checksum method. The maximum frequency
+
of a single checksum has been significantly decreased whichwill lower the probability of
+
a flase positive occuring; this is largely due to the large range of results available to
+
the method. However, there is still room for improvement as the shaded area of the graph
+
indicates that on a smaller scale the frequency of checkmethod 1 varies between high and low
+
values. Eliminating this fluctuation would allow for the data to be spread out more evenly.
+
To improve this
+
method a second layer of multiplication will be implamented, each digit will
+
now be multiplied by a constant depending on its relative position in the BabbleBrick.
+
</p>
+
<p id="pp">
+
<span class="equation">$M_2 = \sum_{p=1}^B \sum_{q=1}^{5}(bp_{(5B_p + q)} + 1) . q . bp$</span><br />
+
<span class="equation" style="font-size:60%;">Or using the remainder modulo '%'</span><br />
+
<span class="equation">$M_2 = \sum_{n=1}^{bp} (bp_n + 1) . ((bp \text{ % } 5) + 1) . bp$</span>
+
<span class="equation_key">
+
$M_2$: Frequency of CheckMethod 2<br />
+
$B$: Number of BabbleBricks in the BabbleBlock<br />
+
$p$: Local integer address of BabbleBrick<br />
+
$q$: Local integer address of base pair in BabbleBrick<br />
+
$B_p$: The $p^{th}$ Babblebrick in the BabbleBlock
+
</span>
+
</p>
+
<div class="col-xs-12" style="width:100%;position:relative;margin:auto;padding:0;">
+
<div class="graph_box col-xs-12">
+
<img src="https://static.igem.org/mediawiki/2016/6/6f/T--Exeter--Collaboration_Edinb_5.png">
+
<span>Fig. 5. The frequency of checkmethod 2 for all possible bits of information in a babbleBlock system containing two BabbleBricks.</span>
+
</div>
+
<div class="graph_box col-xs-12">
+
<img src="https://static.igem.org/mediawiki/2016/0/06/T--Exeter--Collaboration_Edinb_6.png">
+
<span>Fig. 6. The frequency of checkmethod 2 for all possible bits of information in a babbleBlock system containing three BabbleBricks.</span>
+
</div>
+
</div>
+
<p id="pp">
+
<span class="equation">$P_{M_2} = \big(\frac{M_{2\:max}}{F}) \approx \big(\frac{6 \times 10^3}{4^{10}}) = 0.6$% in a 2 BabbleBrick system ($11$% for checksum)</span><br />
+
<span class="equation">$\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\approx \big(\frac{3 \times 10^6}{4^{15}}) = 0.3$% in a 3 BabbleBrick system ($9$% for checksum)</span>
+
<span class="equation_key">
+
$P_{M_2}$: Maximum probability of the same checkmethod 2 value occuring after any number of mutations<br />
+
$M_{2\:max}$: Frequency of most common checkmethod 2 value<br />
+
$F$: Frequency of possible unique bits of information
+
</span>
+
</p>
+
<p id="pp">
+
This has been plotted for a 2 and 3 BabbleBlock system in Fig.5 and Fig.6 respectively.
+
When comparing checksum to checkcethod 2 the frequency peak is approximately 20 to 30
+
times smaller in both cases whilst utilizing more values. In Fig.5 and Fig.6 the largest
+
improvement using the second iteration of the checkmethod is the utilization of every
+
integer value, checkmethod 1 appears shaded as the frequency varies frequently. The last
+
step is to test checkmethod 2 when used in a babbleBlock containing 20 BabbleBricks; the
+
largest value possible assuming a BabbleBlock containing the value ‘3’ in each digit will
+
grant a value of 60600 which falls out of the current limit of 10$^4$ values. Therefore,  
+
it is recommended that one more BabbleBrick is added to the end of the BabbleBlock in order
+
to store 10$^5$ values.  
+
</p>
+
<p id="pp">
+
To improve this method  further more complex multiplications could be added, it would be
+
a decision based on optimising efficiency of calculations and minimising false positives.
+
In a 2 and 3 BabbleBrick system the probability of a false positives occurring was reduced by
+
approximately 20 and 30 times respectively, although the numbers are too large to compute,
+
this new method has the possibility of lowering the maximum false positive error of the previously
+
used checksum by one or more orders of magnitude.
+
If continued further, research should also be done in to the reconstruction of data after it has been lost.
+
</p>
+
 
<div>
 
<div>
 
<a id="Section_link" href="#section_3" style="display:block;margin:20px auto 0 auto;width:14px;"><span style="color:#47BCC2;font-size: 25px;" class="glyphicon glyphicon-menu-down" aria-hidden="true"></span></a>
 
<a id="Section_link" href="#section_3" style="display:block;margin:20px auto 0 auto;width:14px;"><span style="color:#47BCC2;font-size: 25px;" class="glyphicon glyphicon-menu-down" aria-hidden="true"></span></a>
Line 915: Line 803:
 
                 <p id="pp">We collaborated with Glasgow iGEM 2016 to test the efficiency of the T7 Promoter we were using to construct the KillerRed, KillerOrange and Lysozyme kill switches. We new that it was leaky and we speculated that it was reducing the efficiency of our project but we needed proof that the leakiness of the promoter could affect our project. In return they gave us a DH5α.Z1 strain in the hopes it would improve the efficiency of our promoter. After subsequent testing we were unable to express our KillerRed and KillerOrange proteins in this strain. This is the report they sent us for the test of the T7 promoter:</p>
 
                 <p id="pp">We collaborated with Glasgow iGEM 2016 to test the efficiency of the T7 Promoter we were using to construct the KillerRed, KillerOrange and Lysozyme kill switches. We new that it was leaky and we speculated that it was reducing the efficiency of our project but we needed proof that the leakiness of the promoter could affect our project. In return they gave us a DH5α.Z1 strain in the hopes it would improve the efficiency of our promoter. After subsequent testing we were unable to express our KillerRed and KillerOrange proteins in this strain. This is the report they sent us for the test of the T7 promoter:</p>
  
                 <h5>Exeter and Glasgow iGEM 2016 Collaboration: <br \>
+
                  
 
                 <br>
 
                 <br>
 +
<h5>
 
                 KillerRed and KillerOrange Promoter Efficiency Experiment
 
                 KillerRed and KillerOrange Promoter Efficiency Experiment
 
                 </h5>
 
                 </h5>
Line 1,022: Line 911:
 
<br>
 
<br>
  
 +
 +
<div class="row">
 +
    <div class="col-xs-6" style="padding:5px 2% 5px 10%;margin:0;text-align:center">
 +
        <img src="https://static.igem.org/mediawiki/2016/a/a1/T--Exeter--collab-glasgow1_png.png"
 +
style="max-width:100%;margin:auto;display:block;">
 +
            <span class="caption"></span>
 +
<br>
 +
<br>
 +
    </div>
 +
<div class="col-xs-6" style="padding:5px 10% 5px 2%;margin:0; text-align:center">
 +
        <img src="https://static.igem.org/mediawiki/2016/2/2d/T--Exeter--collab-glasgow2_png.png"
 +
style="max-width:100%;margin:auto;display:block;">
 +
            <span class="caption"></span>
 +
<br>
 +
<br>
 +
    </div>
 +
</div>
 
                 <div class="col-xs-12" style="padding:0;margin:0;">
 
                 <div class="col-xs-12" style="padding:0;margin:0;">
                     <img src="https://static.igem.org/mediawiki/2016/a/a1/T--Exeter--collab-glasgow1_png.png" style="max-width:100%;margin:auto;display:block;">
+
                     <img src="" style="max-width:100%;margin:auto;display:block;">
<br>
+
<p id="pp">Fluorescence scan image from the Typhoon with labels for which samples are in each well.</p>
 
<br>
 
<br>
 
                 </div>
 
                 </div>
  
                 <p id="pp">Fluorescence scan image from the Typhoon with labels for which samples are in each well.</p>
+
                  
 
<br>
 
<br>
 
<br>
 
<br>
  
                <div class="col-xs-12" style="padding:0;margin:0;">
+
 
                    <img src="https://static.igem.org/mediawiki/2016/2/2d/T--Exeter--collab-glasgow2_png.png" style="max-width:100%;margin:auto;display:block;">
+
<br>
+
<br>
+
                </div>
+
  
 
                 <p id="pp">These data indicate that there is no difference in fluorescence between either KillerRed or KillerOrange and the cells only control either with or without induction with IPTG. There could be several reasons for this, including the light was not intense enough to excite the fluorescent proteins, however no fluorescence from this type of the test with a laser for excitation would be unlikely.  It is also possible that no protein is being produced, which could be due to insufficient IPTG. However, the RFP in J04450 under the control of the lac-repressible promoter R0010 clearly shows that in the DH5α.Z1 strain, there is less fluorescence without IPTG, than with IPTG. This is not a perfect control for the concentration of IPTG used unless KillerRed and KillerOrange also have the R0010 promoter. Interestingly, in the DH5α strain, there is no significant difference between RFP fluorescence with or without IPTG – this is due to DH5α not having a functional copy of LacI, the lac repressor, therefore lac-repressible promoters are not “OFF”, so cannot be switched “ON” by IPTG induction. </p>
 
                 <p id="pp">These data indicate that there is no difference in fluorescence between either KillerRed or KillerOrange and the cells only control either with or without induction with IPTG. There could be several reasons for this, including the light was not intense enough to excite the fluorescent proteins, however no fluorescence from this type of the test with a laser for excitation would be unlikely.  It is also possible that no protein is being produced, which could be due to insufficient IPTG. However, the RFP in J04450 under the control of the lac-repressible promoter R0010 clearly shows that in the DH5α.Z1 strain, there is less fluorescence without IPTG, than with IPTG. This is not a perfect control for the concentration of IPTG used unless KillerRed and KillerOrange also have the R0010 promoter. Interestingly, in the DH5α strain, there is no significant difference between RFP fluorescence with or without IPTG – this is due to DH5α not having a functional copy of LacI, the lac repressor, therefore lac-repressible promoters are not “OFF”, so cannot be switched “ON” by IPTG induction. </p>
Line 1,046: Line 948:
 
<br>
 
<br>
 
<br>
 
<br>
 
+
<div class="row">
<div class="col-xs-12" style="padding:0;margin:0;">
+
    <div class="col-xs-6" style="padding:5px 2% 5px 10%;margin:0;text-align:center">
                    <img src="https://static.igem.org/mediawiki/2016/4/44/T--Exeter--collab-glasgow3_png.png" style="max-width:100%;margin:auto;display:block;">
+
        <img src="https://static.igem.org/mediawiki/2016/4/44/T--Exeter--collab-glasgow3_png.png"  
<br>
+
style="max-width:100%;margin:auto;display:block;">
<br>
+
            <span class="caption"></span>
                </div>
+
<br>
 
+
<br>
<div class="col-xs-12" style="padding:0;margin:0;">
+
    </div>
                    <img src="https://static.igem.org/mediawiki/2016/5/53/T--Exeter--collab-glasgow4_png.png" style="max-width:100%;margin:auto;display:block;">
+
<div class="col-xs-6" style="padding:5px 10% 5px 2%;margin:0; text-align:center">
<br>
+
        <img src="https://static.igem.org/mediawiki/2016/5/53/T--Exeter--collab-glasgow4_png.png"  
<br>
+
style="max-width:100%;margin:auto;display:block;">
                </div>
+
            <span class="caption"></span>
 +
<br>
 +
<br>
 +
    </div>
 +
</div>        
  
 
                 <p id="pp">Both plasmids had the BioBrick prefix, and the correct sequence for both KillerRed and KillerOrange open reading frame, according to the papers cited on the Exeter 2016 iGEM wiki. The sequence between the prefix and the ATG start codon, we checked against lac-repressible promoters in the iGEM registry. We found a match to R0184, which is a T7 lac-repressible promoter. T7 promoters require T7 polymerase to be transcribed, as they are not recognised by E. coli polymerases. This results confirms the result of the fluorescence measurements. No KillerRed or KillerOrange protein was observed by fluorescence, as neither gene was being transcribed by either DH5α or DH5α.Z1 as neither strain produces the required T7 polymerase. A protein overexpression E. coli strain such as BL21<DE3> which has the T7 polymerase gene inserted into its genome is designed to use T7 promoters would have been able to express these KillerRed and KillerOrange constructs.</p>
 
                 <p id="pp">Both plasmids had the BioBrick prefix, and the correct sequence for both KillerRed and KillerOrange open reading frame, according to the papers cited on the Exeter 2016 iGEM wiki. The sequence between the prefix and the ATG start codon, we checked against lac-repressible promoters in the iGEM registry. We found a match to R0184, which is a T7 lac-repressible promoter. T7 promoters require T7 polymerase to be transcribed, as they are not recognised by E. coli polymerases. This results confirms the result of the fluorescence measurements. No KillerRed or KillerOrange protein was observed by fluorescence, as neither gene was being transcribed by either DH5α or DH5α.Z1 as neither strain produces the required T7 polymerase. A protein overexpression E. coli strain such as BL21<DE3> which has the T7 polymerase gene inserted into its genome is designed to use T7 promoters would have been able to express these KillerRed and KillerOrange constructs.</p>
Line 1,074: Line 980:
  
 
                 <p id="pp">Glasgow iGEM did fantastic work for us, providing us with detailed analysis of the T7 promoter and suggestions for improving the efficiency of our project. Whilst their data on the DH5alpha Z1 strain is accurate and in accordance with subsequent research and advice, we have since noted there is expression of KillerRed and KillerOrange in DH5alpha in lab tests.  </p>
 
                 <p id="pp">Glasgow iGEM did fantastic work for us, providing us with detailed analysis of the T7 promoter and suggestions for improving the efficiency of our project. Whilst their data on the DH5alpha Z1 strain is accurate and in accordance with subsequent research and advice, we have since noted there is expression of KillerRed and KillerOrange in DH5alpha in lab tests.  </p>
 +
<style>
 +
ul{
 +
list-style-image:none;
 +
}
 +
.container ul{
 +
padding-top:20px;
 +
padding-right:40px;
 +
padding-left:80px;
 +
font-size:150%;
 +
}
 +
.container ul li {
 +
/* Text color */
 +
color: #333;
 +
list-style-type: none;
 +
}
  
<div>
+
.container ul li:before {
 +
/* Unicode bullet symbol */
 +
content: '\25AA';
 +
/* Bullet color */
 +
color: #47BCC2;
 +
padding-right: 0.5em;
 +
}
 +
ol{
 +
padding-top:20px;
 +
padding-right:40px;
 +
padding-left:80px;
 +
font-size:150%;
 +
}
 +
ol li {
 +
/* Text color */
 +
color: #333;
 +
list-style-type: none;
 +
}
 +
ol li {
 +
list-style-type: none;
 +
counter-increment: list;
 +
position: relative;
 +
}
 +
 
 +
ol li:before {
 +
content: counter(list) ".";
 +
position: absolute;
 +
left: -2.5em;
 +
width: 2em;
 +
text-align: right;
 +
color: #47BCC2;
 +
}
 +
</style>
 +
 
 +
<div>
 
<a id="Section_link" href="#section_4" style="display:block;margin:20px auto 0 auto;width:14px;"><span style="color:#47BCC2;font-size: 25px;" class="glyphicon glyphicon-menu-down" aria-hidden="true"></span></a>
 
<a id="Section_link" href="#section_4" style="display:block;margin:20px auto 0 auto;width:14px;"><span style="color:#47BCC2;font-size: 25px;" class="glyphicon glyphicon-menu-down" aria-hidden="true"></span></a>
 
</div>
 
</div>
 
</div>
 
</div>
<div class="col-xs-12 div_content">
+
<div class="col-xs-12 div_content">
 
<div id="section_4" class="link_fix"></div>
 
<div id="section_4" class="link_fix"></div>
 
<div id="contentTitle">
 
<div id="contentTitle">
Skype and Meet-ups
+
Theory: Edinburgh
 
</div>
 
</div>
 +
<h6>Optimising methods of data mutation detection in BabbleBlocks</h6>
 +
<p id="pp">
 +
Edinburgh’s 2016 under-graduate team is utilising the natural information storage capability of DNA to store digital information. Currently they have outlined a method for using a base 4 system to store words in biological material called “BabbleBlocks”. During the Westminster UK iGEM meetup Edinburgh talked about the issue of mutated DNA going relatively undetected. Their method at the time involved adding up the value of each base and storing this as a “Checksum” at the end of the BabbleBlock. Edinburgh’s team highlighted in their presentation that they knew this would lead to a large amount of false positives as many different combinations of information could add to the same Checksum. My research looks in to the method of the Checksum and attempts to create a new method that has a smaller chance of false positives.
 +
</p>
 +
 +
 +
<p id="pp">
 +
Storing information on DNA offers many advantages over current methods, however mutations
 +
need to be carefully monitored to ensure incorrect data is not read as a false positive.
 +
Currently for information stored on a BabbleBrick a ‘CheckSum’ is calculated by taking the
 +
sum of the values on each base of DNA. If the checksum of a BabbleBlock has changed between
 +
the time of writing and reading, the data is considered to be corrupt.
 +
</p>
 +
<p id="pp">
 +
<span class="equation">$C = \sum^{bp}_{n=1} bp_n$</span><br />
 +
<span class="equation_key">
 +
$C$: Frequency of checksum<br />
 +
$n$: The integer address of base pair<br />
 +
$bp$: Amount of base pairs (5 times the number of BabbleBricks)<br />
 +
$bp_n$: The value of the $n^{th}$ base pair
 +
</span>
 +
</p>
 +
<div class="col-xs-12" style="width:100%;position:relative;margin:auto;padding:0;">
 +
<div class="graph_box col-xs-12">
 +
<img src="https://static.igem.org/mediawiki/2016/4/48/T--Exeter--Collaboration_Edinb_1.png">
 +
<span>Fig. 1. The frequency of all checksums in a babbleBlock system containing two BabbleBricks.</span>
 +
</div>
 +
<div class="graph_box col-xs-12">
 +
<img src="https://static.igem.org/mediawiki/2016/0/0b/T--Exeter--Collaboration_Edinb_2.png">
 +
<span>Fig. 2. The frequency of all checksums in a babbleBlock system containing three BabbleBricks.</span>
 +
</div>
 +
</div>
 +
<p id="pp">
 +
Currently a checksum utilizes only a small percentage of the values that can be stored.
 +
A BabbleBrick contains 5 base 4 digits meaning that 4$^{\text{5}B}$ unique bits of
 +
information share one of 15$B$ checksums where $B$ is the amount of BabbleBricks in one
 +
BabbleBlock. This data has been plotted for BabbleBlocks containing 2 and 3 BabbleBricks
 +
in Fig.1 and Fig.2 respectively. Assuming that between the time of writing and reading
 +
any number of mutations can occur, the maximum probability of a mutation event resulting
 +
in the same checksum can be calculated by comparing the frequency of one checksum to the
 +
total frequency of unique bits of information.
 +
</p>
 +
<p id="pp">
 +
<span class="equation">$P_C = \big(\frac{C_{max}}{F}) \approx \big(\frac{1.2 \times 10^5}{4^{10}}) = 11$% in a 2 BabbleBrick system</span><br />
 +
<span class="equation">$\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\approx \big(\frac{10^8}{4^{15}}) = 9$% in a 3 BabbleBrick system</span>
 +
<span class="equation_key">
 +
$P_C$: Maximum probability of the same checksum occuring after any number of mutations<br />
 +
$C_{max}$: Frequency of most common checksum<br />
 +
$F$: Frequency of possible unique bits of information
 +
</span>
 +
</p>
 +
<p id="pp">
 +
Therefore, it can be predicted that for an average sentence containing 9 words the maximum
 +
probability of the same checksum occurring will be of the magnitude of 1%. The probability
 +
should decrease marginally when adding BabbleBricks due to the slightly increased range of
 +
checksums that become available. This value can be optimized by altering the method of the
 +
checksum to utilize a greater range of values and to spread out the frequency more evenly as
 +
to reduce the maximum probability of the same checksum occurring.
 +
</p>
 +
<p id="pp">
 +
Currently one BabbleBlock has 4 BabbleBricks dedicated to storing the checksum, giving a maximum
 +
10$^4$ possible values. The first step in determining a ‘CheckMethod’ is to ensure that all checksums
 +
for a suitable amount of BabbleBricks can be stored without going over 10$^4$. It is also important
 +
to not use operators that will result in negative numbers or decimals, therefore limiting the
 +
possible checksum values to integers up to but not including 10$^4$, this rules out operators such
 +
as subtract and divide. For this example, a suitable number of words in a sentence and therefore
 +
BabbleBricks in a BabbleBlock shall be 20. All simulations will be carried out on 3 BabbleBrick
 +
systems due to computing limitations.
 +
</p>
 +
<p id="pp">
 +
Checksums are non-directional, for example a BabbleBrick of bases [2,2,2,2,2] would have the
 +
same checksum as [2,1,3,2,2].  To alter this a checkmethod will incorporate the position
 +
of the base in to the calculation. At each point the digit is multiplied by its position
 +
in the BabbleBlock, where the first BabbleBrick has digit positions 1 to 5 and the last
 +
BabbleBrick (20$^{th}$) has positions 96 to 100. A scaler $\alpha$ has been included to
 +
increase the range of results. To ensure multiplications don’t result in a null result
 +
the value of each base had a value of 1 added to it. The first checkemethod of one
 +
BabbleBlock can be defined as:
 +
</p>
 +
<p id="pp">
 +
<span class="equation">$M_1 = \sum_{n=1}^{bp}(bp_n + 1) . \alpha . bp$</span>
 +
<span class="equation_key">
 +
$M_1$: Frequency of CheckMethod 1<br />
 +
$\alpha$: Scaler ($\alpha = 5$ in this example)
 +
</span>
 +
</p>
 +
<div class="col-xs-12" style="width:100%;position:relative;margin:auto;padding:0;">
 +
<div class="graph_box col-xs-12">
 +
<img src="https://static.igem.org/mediawiki/2016/4/4c/T--Exeter--Collaboration_Edinb_3.png">
 +
<span>Fig. 3. The frequency of checkmethod 1 for all possible bits of information in a babbleBlock system containing two BabbleBricks.</span>
 +
</div>
 +
<div class="graph_box col-xs-12">
 +
<img src="https://static.igem.org/mediawiki/2016/d/d7/T--Exeter--Collaboration_Edinb_4.png">
 +
<span>Fig. 4. The frequency of checkmethod 1 for all possible bits of information in a babbleBlock system containing three BabbleBricks.</span>
 +
</div>
 +
</div>
 +
<p id="pp">
 +
This method results in Fig.3 and Fig.4 for a 2 and 3 BabbleBlock system respectively,
 +
which shows a large improvement over the original checksum method. The maximum frequency
 +
of a single checksum has been significantly decreased whichwill lower the probability of
 +
a flase positive occuring; this is largely due to the large range of results available to
 +
the method. However, there is still room for improvement as the shaded area of the graph
 +
indicates that on a smaller scale the frequency of checkmethod 1 varies between high and low
 +
values. Eliminating this fluctuation would allow for the data to be spread out more evenly.
 +
To improve this
 +
method a second layer of multiplication will be implamented, each digit will
 +
now be multiplied by a constant depending on its relative position in the BabbleBrick.
 +
</p>
 +
<p id="pp">
 +
<span class="equation">$M_2 = \sum_{p=1}^B \sum_{q=1}^{5}(bp_{(5B_p + q)} + 1) . q . bp$</span><br />
 +
<span class="equation" style="font-size:60%;">Or using the remainder modulo '%'</span><br />
 +
<span class="equation">$M_2 = \sum_{n=1}^{bp} (bp_n + 1) . ((bp \text{ % } 5) + 1) . bp$</span>
 +
<span class="equation_key">
 +
$M_2$: Frequency of CheckMethod 2<br />
 +
$B$: Number of BabbleBricks in the BabbleBlock<br />
 +
$p$: Local integer address of BabbleBrick<br />
 +
$q$: Local integer address of base pair in BabbleBrick<br />
 +
$B_p$: The $p^{th}$ Babblebrick in the BabbleBlock
 +
</span>
 +
</p>
 +
<div class="col-xs-12" style="width:100%;position:relative;margin:auto;padding:0;">
 +
<div class="graph_box col-xs-12">
 +
<img src="https://static.igem.org/mediawiki/2016/6/6f/T--Exeter--Collaboration_Edinb_5.png">
 +
<span>Fig. 5. The frequency of checkmethod 2 for all possible bits of information in a babbleBlock system containing two BabbleBricks.</span>
 +
</div>
 +
<div class="graph_box col-xs-12">
 +
<img src="https://static.igem.org/mediawiki/2016/0/06/T--Exeter--Collaboration_Edinb_6.png">
 +
<span>Fig. 6. The frequency of checkmethod 2 for all possible bits of information in a babbleBlock system containing three BabbleBricks.</span>
 +
</div>
 +
</div>
 +
<p id="pp">
 +
<span class="equation">$P_{M_2} = \big(\frac{M_{2\:max}}{F}) \approx \big(\frac{6 \times 10^3}{4^{10}}) = 0.6$% in a 2 BabbleBrick system ($11$% for checksum)</span><br />
 +
<span class="equation">$\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\:\approx \big(\frac{3 \times 10^6}{4^{15}}) = 0.3$% in a 3 BabbleBrick system ($9$% for checksum)</span>
 +
<span class="equation_key">
 +
$P_{M_2}$: Maximum probability of the same checkmethod 2 value occuring after any number of mutations<br />
 +
$M_{2\:max}$: Frequency of most common checkmethod 2 value<br />
 +
$F$: Frequency of possible unique bits of information
 +
</span>
 +
</p>
 +
<p id="pp">
 +
This has been plotted for a 2 and 3 BabbleBlock system in Fig.5 and Fig.6 respectively.
 +
When comparing checksum to checkcethod 2 the frequency peak is approximately 20 to 30
 +
times smaller in both cases whilst utilizing more values. In Fig.5 and Fig.6 the largest
 +
improvement using the second iteration of the checkmethod is the utilization of every
 +
integer value, checkmethod 1 appears shaded as the frequency varies frequently. The last
 +
step is to test checkmethod 2 when used in a babbleBlock containing 20 BabbleBricks; the
 +
largest value possible assuming a BabbleBlock containing the value ‘3’ in each digit will
 +
grant a value of 60600 which falls out of the current limit of 10$^4$ values. Therefore,
 +
it is recommended that one more BabbleBrick is added to the end of the BabbleBlock in order
 +
to store 10$^5$ values. 
 +
</p>
 +
<p id="pp">
 +
To improve this method  further more complex multiplications could be added, it would be
 +
a decision based on optimising efficiency of calculations and minimising false positives.
 +
In a 2 and 3 BabbleBrick system the probability of a false positives occurring was reduced by
 +
approximately 20 and 30 times respectively, although the numbers are too large to compute,
 +
this new method has the possibility of lowering the maximum false positive error of the previously
 +
used checksum by one or more orders of magnitude.
 +
If continued further, research should also be done in to the reconstruction of data after it has been lost.
 +
</p>
 +
<div>
 +
<a id="Section_link" href="#section_5" style="display:block;margin:34vh auto 0 auto;width:14px;"><span style="color:#47BCC2;font-size: 25px;" class="glyphicon glyphicon-menu-down" aria-hidden="true"></span></a>
 +
</div>
 +
</div>
 +
<div class="col-xs-12 div_content">
 +
<div id="section_5" class="link_fix"></div>
 +
<div id="contentTitle">
 +
Stanford Brown
 +
</div>
 +
<div class="col-xs-12 audio_controls">
 +
 +
<p id="pp">
 +
  We initiated contact with Stanford-Brown this year with the intention of interviewing one of their supervisors, Prof. Lynn Rothschild. We were interested in hearing     
 +
  about her opinions as well as experiences with diversity and equality in science. Unfortunately we were never able to find a mutually suitable date to carry out the 
 +
  interview. However we were able to organise a collaboration with her team.
 +
</p>
 +
<p id="pp">
 +
  The Stanford-Brown team have helped our podcast and YouTube series by making their own edition of Desert Island… Science? Which is now available on our 
 +
  YouTube and SoundCloud channels.
 +
</p>
 +
<audio controls style="max-width:100%;display:block;margin:0 auto;">
 +
<source src="https://static.igem.org/mediawiki/2016/7/7f/T--Exeter--Collab_stanfordaudioogg.ogg" type="audio/ogg">
 +
<source src="https://static.igem.org/mediawiki/2016/a/a7/T--Exeter--Log_31.5.16vlogmp3.mp3" type="audio/mpeg">
 +
Your browser does not support the audio element.
 +
</audio>
 +
<p id="pp">
 +
  We are very thankful to Stanford-Brown for their contribution, as it has helped our work get further recognition on an international scale.
 +
  </p>
 +
<p id="pp">We are also proud and grateful in saying that we have helped and been helped by various other teams in this years iGEM competition. Utilising other teams equipment and different ways of thinking towards solving problems has provided us all with some great data and innovative solutions to some problems we have encountered. We are confident that what we have achieved will benefit the iGEM competition as a whole. </p>
 +
 +
<p id="pp">Good inter-team communication is a vital factor in all disciplines and at the core of the iGEM spirit. We hope to have contributed to this in several ways. </p>
 +
</div>
 
</div>
 
</div>
 
</div>
 
</div>

Latest revision as of 02:43, 20 October 2016