ETH Zurich 2006

From 2006.igem.org

(Difference between revisions)
Jump to: navigation, search
(Constructor (aka Project X))
(added link to FTD article)
 
(550 intermediate revisions not shown)
Line 1: Line 1:
-
== Introduction ==
+
<center>[[Image:ETH_2006_pic_for_frontpage.jpg|ETH Team 2006]]
 +
<BR/><b>standing (L-R):</b> Marco, Alexandra, Arthur, Olga, Dimo, Marko, Robert; <b>in front (L-R):</b>
 +
Franz, Michael</center>
 +
<br><br>
-
* [[About us]]
+
<center>
 +
'''>>>>>>>>>>>> [http://www.zfranz.ch.vu/iGEM/ETH-iGEM-%202006-%20presentation.pdf Download ETH iGEM presentation 2006 as PDF] <<<<<<<<<<<<'''
 +
</center>
-
== People ==
+
<center>
 +
'''>>>>>>>>>>>>> [http://www.fotofranz.ch.vu/igem See pictures of the iGEM Jamboree in Boston] <<<<<<<<<<<<<'''
 +
</center>
-
=== Students ===
+
<center>
-
{| width=700
+
'''>>>>>>>>>>>>> [http://ftd.de/forschung/154366.html Read article in Financial Times Deutschland: &quot;Eins plus eins gleich Gr&uuml;n&quot; (german only)] <<<<<<<<<<<<<'''
-
|[[Simon Barkow]]
+
</center>
-
|[[Christophe Dessimoz]]
+
<br><br>
-
|[[User:Zladdi|Zlatko Franjcic]]
+
 
 +
<blockquote>
 +
Adding numbers is easy, isn't it? 1234 plus 5678, for example, is 6912. But how do engineers add binary numbers instead of decimal ones? And how, in the end, can this be done by a living cell?
 +
 
 +
We, the members of the ETH Zurich 2006 iGEM team, are currently working on these questions, whereas the last one seems to be not trivial.<br><br>
 +
 
 +
What the addition of numbers has to do with pattern recognition, how our model and the mathematical analysis look like, and how the experiments are realized will be explained on these wiki pages. We wish you a pleasant time with our pages. Enjoy it!
 +
</blockquote>
 +
 
 +
<br><br>
 +
 
 +
== Coordination ==
 +
 
 +
=== TODOs ===
 +
 
 +
==== Modeling ====
 +
 
 +
*'''Parts''' Model the whole System with Sensing, PoPS duplexer and Half adder (Marco and Franz) -- probably not
 +
*Model whether a different strength of input is necessary for the AND and XOR Gates (Marco)
 +
*Finish modeling the second AND Gate and find a biological way to implement it and write the DNA and order it (Marco and Robert) -- probably not
 +
* Bring model parameter up to date &amp; update simulation results/senisitivity analysis (Marco)
 +
 
 +
==== Lab ====
 +
 
 +
Responsible: Robert for the preparatory experiments, Olga for the assembly and testing of the gates.
 +
 
 +
*Read the literature on the XOR and AND Gates, check carefully for strains needed and compatibility of the parts (Who?)
 +
*Prepare a protocol for parts assembly (Olga)
 +
 
 +
==== Documentation ====
 +
 
 +
Responsible: Alexandra for the registry, Arthur for the Wiki.
 +
 
 +
* enter lab experience report to registry
 +
* Make a drawing of the DNA to have an overview of which parts will be consecutively on the same DNA piece (Alexandra) (this is part of the [[#System deployment]] section --[[User:Ajk|Ajk]])
 +
* Revise images &amp; graphics (Marco):
 +
** correct errors
 +
** unify symbols
 +
** extract missing ones from slides, see [[ETH 2006 Docs And Links|here]]
 +
 
 +
==== Presentation/Poster and PR====
 +
 
 +
Responsible: Franz for the presentation, Dimo for PR/Poster
 +
 
 +
* design and write the final presentation (with LaTex beamer class) IN PROCESS
 +
 
 +
Structure:
 +
 
 +
1. Introduction of the team and ETH Zurich and of the half-adder idea -  about 3 min
 +
 
 +
2. Engineering Part  -  about 9 min
 +
 
 +
3. Biological part  -  about 8 min
 +
 
 +
(4.) Questions from the audience  -  10min (I think, Marco (modelling) and Marko (biology) should also be ready to answer questions)
 +
 
 +
=== Schedule ===
 +
 
 +
Available as Google Calendar: [http://www.google.com/calendar/render?cid=pqi8ni6gnfj5r3o0np0h4smrr4@group.calendar.google.com iGEM 2006 ETH Zurich]
 +
 
 +
;past:see [[ETH Schedule Archive|here]]
 +
;16.11.: Jamboree wrap up (with T-Shirts!), 5pm at CNB seminar room
 +
 
 +
=== Team members ===
 +
{| cellspacing="0px" cellpadding="5px" style="border-style:solid;border-width:thin;border-color:#dddddd;" rules="all"
|-
|-
-
|[[Dominic Frutiger]]
+
| [[User:Paolo Pinkel|Michael Friedmann]] || [[User:Dimo|Dimo Brockhoff]] || [[Franz|Franz Zürcher]]
-
|[[Robin Künzler]]
+
-
|[[User:realUACM|Urs A. Müller]]
+
|-
|-
-
|[[User:Jonas|Jonas Nart]]
+
| [[Olga Nikolayeva]] || [[User:Choutkoa|Alexandra Choutko]] || [[User:Ajk|Arthur Korn]]
-
|[[Kristian Nolde]]
+
-
|[[Alexander Roth]]
+
-
|-
+
-
|[[User:Tamara|Tamara Ulrich]]
+
-
|[[Giorgia Valsesia]]
+
-
|[[Herve Vanderschuren]]
+
|-
|-
 +
| [[User:Rschuetz|Robert Schütz]] || [[User:Terzerm|Marco Terzer]] || [[Marko Jovanovic]]
|}
|}
-
=== Supervisors ===
+
== Finding a Project ==
-
{| width=650
+
-
|[[Jörg Stelling]]
+
-
|[[Sven Panke]]
+
-
|[[Eckart Zitzler]]
+
-
|}
+
-
=== Advisors ===
+
-
{| width=650
+
-
|[[Uwe Sauer]]
+
-
|[[Martin Fussenegger]]
+
-
|[[Andreas Hierlemann]]
+
-
|-
+
-
|[[Kay-Uwe Kirstein]]
+
-
|[[Ruedi Aebersold]]
+
-
|}
+
-
== Events & Timeline ==
+
Finding a project to work on is not easy. Not because it is hard to find interesting projects but because there are too many of them. In the first weeks we did a lot of brainstorming including thoughts about the projects' feasibility. You can find a list of ideas [[ETH 2006 Ideas|here]].
-
* [[Upcoming Talks]]
+
During the weeks, we decided to split up the whole team into two groups. Each group proposed a project after these two weeks of separated work:
-
* [[Meetings]]
+
* [[ETH 2006 Meat Monitor|Meat monitor project]] (Michael, Dimo, Olga, Arthur, Marko)
 +
* [[ETH 2006 Half adder|Half adder/pattern recognition project]] (Franz, Alexandra, Robert, Marco)
-
* [[Timeline]]
+
After the proposals, we decided to further pursue the half adder project idea.
 +
== Design process ==
-
== Project Ideas ==
+
=== System behavorial specification ===
-
This is the brainstorming section. In this section you will find random ideas and comments without too much consideration of feasability etc. Crazy ideas and wild dreams are welcome!
+
-
=== Individual Phenomena ===
+
-
Designing and tweaking so that the individual behaves in a desired way.
+
-
* [[Buffer Bacteria]]
+
-
* [[Random Number Generator]]
+
-
* [[Linear Amplifier]]
+
-
=== Oscillator-based Phenomena ===
+
# Write something with a chemical on a petri plate (like '''ETH''' for example)
-
Some clocking behaviors, such as counters and integrators etc.
+
# Let Bacteria grow uniformly on the plate
-
* [[Generation Counter]]
+
# Expose the plate to a picture (black and white) of the same pattern
-
* [[Oscillation Counter]]
+
# Result:
-
* [[Swiss Watch]]
+
#*Bacteria gets green when pattern on the plate and picture match (light and chemical)
 +
#*Bacteria does not express fluorescent protein when pattern on the plate and picture match (no light and no chemical)
 +
#*Bacteria gets red when pattern on the plate and picture do not match
-
=== Collaborative Phenomena ===
+
            light  no light
-
Some of us have a great interest in some form of emergent phenomena and group dynamics based on simple local rules and external stimulae. Examples would be behaviors like sorting, pattern detections, flocking etc.
+
chemical    A        B
-
* [[Edge Detection]]
+
no chemical  B        C
-
* [[Constructor Bacteria]]
+
-
* [[Sorting Bacteria]]
+
-
* [[Predator-Prey Behavior]]
+
-
* [[Pulser]]
+
 +
The outputs can be reported by fluorescent proteins, the mapping of states to outputs is arbitary, our choice is:
-
== Development Groups ==
+
A: green
-
We decided to cluster related projects and to form groups which will dedicate their time to this cluster. The goal is to converge to some single preferred solution based on these project ideas while keeping an eye on feasability, coolness, usefulness, and modular architecture on the way.
+
B: red
 +
C: no fluorescence
-
If you are in no group yet, please choose one.
 
-
===[[Quorum Sensing based]] (Dominic, Giorgia, Herve)===
+
An experiment in the lab could for instance look like this:
-
*[[Sorting Bacteria]]
+
-
*[[Pulser]]
+
-
*[[Constructor Bacteria]]
+
-
*[[Controlled Cell Division]]
+
-
*[[Predator-Prey Behavior]]
+
-
===[[Oscillator based]] (Urs, Christophe, Jonas)===
 
-
*[[Generation Counter]]
 
-
*[[Oscillation Counter]]
 
-
*[[Swiss Watch]]
 
-
===[[Generation based]] (-)===
+
[[image:ETH_Pattern_Experiment.png|center|400px|pattern experiment]]
-
*[[Generation Counter]]
+
-
*[[Changing Generation Colors]]
+
-
===[[Other projects]] (Jonas, Simon, Dominic)===
 
-
*[[Edge Detection]]
 
-
*[[Buffer Bacteria]]
 
-
== Merged Projects ==
+
or like this:
-
The two projects below are the outcome of the work of our two remaining development groups. They both have their pros and cons and the discussion continues until at least Monday evening.
+
 +
[[image:ETH_Eth_Experiment.png|center|300px|eth experiment]]
-
* [[Project X| Project X aka "SO-Constructor"]] by the development group for the [[Quorum_Sensing_based]] projects.
+
Considering the green and the red output as being separate, the logic mapping the input states to the output states is AND for the GFP and XOR for the RFP. Together they amount to a half adder logic.
-
* [[Oscillator_based| Counter aka "The Thing"]] by the corresponding development group for [[Oscillator_based]] projects.
+
 +
The whole system is only considered at it's steady state, dynamic processes are only of minor interest.
-
== Ballot ==
+
=== System structure ===
-
Please everybody make your vote (1 means "forget it" and 10 means "definitely a Nature paper") on the four criteria.
+
-
=== Constructor (aka Project X) ===
+
The whole process can be brought into a common input, logic, output form:
-
<table width="252" border="1" cellspacing="2" cellpadding="1">
+
[light sensing]----->[      ]-->[reporter A]
-
<tr>
+
                      [ logic ]
-
<td><b>CONSTRUCTOR</b></td>
+
[chemical sensing]-->[      ]-->[reporter B]
-
<td><b>Urs </b></td>
+
-
<td><b>Tamara </b></td>
+
-
<td><b>Jonas </b></td>
+
-
<td><b>Zlatko </b></td>
+
-
<td><b>Giorgia </b></td>
+
-
<td><b>Simon </b></td>
+
-
<td><b>Kristian </b></td>
+
-
<td><b>Herve </b></td>
+
-
<td><b>Dominic </b></td>
+
-
<td><b>Alexander </b></td>
+
-
<td><b>Christophe </b></td>
+
-
<td><b>Robin </b></td>
+
-
</tr>
+
-
<tr>
+
-
<td><b>Usefulness </b></td>
+
-
<td>6</td>
+
-
<td>7</td>
+
-
<td>7</td>
+
-
<td>7</td>
+
-
<td>-</td>
+
-
<td>6</td>
+
-
<td>-</td>
+
-
<td>-</td>
+
-
<td>-</td>
+
-
<td>8</td>
+
-
<td>-</td>
+
-
<td>7</td>
+
-
</tr>
+
-
<tr>
+
-
<td><b>Feasability </b></td>
+
-
<td>4</td>
+
-
<td>8</td>
+
-
<td>6</td>
+
-
<td>6?</td>
+
-
<td>-</td>
+
-
<td>5</td>
+
-
<td>-</td>
+
-
<td>-</td>
+
-
<td>-</td>
+
-
<td>4</td>
+
-
<td>-</td>
+
-
<td>6</td>
+
-
</tr>
+
-
<tr>
+
-
<td><b>Modularity </b></td>
+
-
<td>10</td>
+
-
<td>8</td>
+
-
<td>6</td>
+
-
<td>10</td>
+
-
<td>-</td>
+
-
<td>9</td>
+
-
<td>-</td>
+
-
<td>-</td>
+
-
<td>-</td>
+
-
<td>6</td>
+
-
<td>-</td>
+
-
<td>7</td>
+
-
</tr>
+
-
<tr>
+
-
<td><b>Coolness </b></td>
+
-
<td>9</td>
+
-
<td>7</td>
+
-
<td>8</td>
+
-
<td>10</td>
+
-
<td>-</td>
+
-
<td>9</td>
+
-
<td>-</td>
+
-
<td>-</td>
+
-
<td>-</td>
+
-
<td>7</td>
+
-
<td>-</td>
+
-
<td>8</td>
+
-
</tr>
+
-
</table>
+
-
<p>
+
 +
As it turns out, a [http://en.wikipedia.org/wiki/Full_adder half-adder] can be used as logic part. To understand what a half-adder is, let us first have a brief look at how we add numbers by hand.
-
=====Additional Comments:=====
+
If we add two (large) numbers, we usually start with the least significant digits and add these two digits:
-
'''Tamara:'''
+
  1234
-
  As an engineer, I think the counter is completely useful and totally cool as well. I'm really
+
  + 9684
-
  excited at the prospect that it might actually work (which I frankly still doubt a little bit at
+
  ------
-
the moment). The SO-Constructor definitely is cool as well, but I don't see it's usefulness yet,
+
  ....8
-
but as I'm no bilogist, it is not mine to judge.
+
-
Talking about modularity, I see that the SO-Constructor has a lot of modules, but they are not
+
-
'parallel' modules, but 'serial' modules, i.e. if one module fails, the overlaying modules won't
+
-
work as well. They strongly depend on each other. I also see the problem of tuning, because there
+
-
is a real lot of tuning to do and nearly everything needs to be tuned. For me, some questions
+
-
arise like: Can you simply change the threshold for a certain protein in quorum sensing? Anyway,
+
-
the probability that we have some results to present in the end is still relatively high.
+
-
I don't think the counter is really modular, altough it is a combination of one basic part (the
+
-
'thing'). The point is, if that basic part works, the whole counter probably works as well. If it
+
-
doesn't, then we don't have anything at all. But shouldn't we just take the risk and try it? No
+
-
risk, no fun :-)
+
-
Conclusion: The SO-Constructor is in my opinion the 'safer' option, meaning that we are much more 
+
-
probable to get something that actually works. Whereas the Counter is much more useful and
+
-
revolutionary, at least when we get to work it somehow.
+
-
'''Dominic:'''
+
In the example, the digit's sum is smaller than 10. Thus, we do not need to keep the carry-over in mind (it is zero in this case). For the second digit, the sum is 11 and we have to memorize the carry 1 and so forth:
-
As I already have said during the meeting, I am a little bit concerned about the effects of the
+
-
different presentation styles and levels of detail: it is hard to judge the feasability of one or
+
-
the other, since for the SO-Constructor I can see a clear stepwise approach with controllable
+
-
biological units to implement, but I am doubtful about the tuning and proper interplay of all these
+
-
components - although I am confident that to some degree this can be achieved.  
+
-
As for the Counter I am also not sure about the basic biological assumptions, e.g. whether the
+
-
toggle switch units are available and will work as well as the symmetric repression/activation
+
-
that is necessary, although the modeling part suggests everything is straightforward - but this
+
-
might be deceiving.
+
-
It is hard for me to judge the biological unpredictabilites and risks, but from an engineering
+
-
point of view the Counter building block is of the more useful thing to do, since it has a broad
+
-
application range thanks to the clear interfaces.
+
-
Last but not least such a technical unit seems more suitable in the context of Synthetic Biology.
+
-
'''Urs:'''
+
  1234      1234      1234      1234
-
  I think if the whole thing works this project is astonishing. But I'm in doubt about it. The fact
+
  + 9684    + 9684    + 9684    + 9684
-
that you could model each step seperatly is of course a big advantage of this project. The
+
    1                  1
-
  probability that at least a few of the steps work is quite high and so you will see some results at
+
  ------    ------    ------    ------
-
the end. I'm not so sure about the usefulness. To encapsulate some bacterias which produce a
+
  ...18      ..918      .0918    10918
-
certain substance could be usefull but I'm not an expert in this stuff.
+
-
'''Addition:''' Hervé, I think those who said, that they doubt about the feasibility of the
+
-
Constructor Bacteria didn't mean, that it doesn't work at all. I'm rather sure that at least
+
-
some parts will show the wanted behaviour but I also think that it is unlikely that really the
+
-
whole thing works. Further ideas and knowledge about how we could implement both projects in detail
+
-
will increase the probability that we will succeed (for both projects).
+
-
'''Zlatko:'''
+
In general, each addition step produces the sum, consisting of the current digit of the sum and the carry digit. The only difference between the first and the other steps are the ''inputs'': When the addition starts, there is no carry bit. The inputs are the two least significant digits of our two numbers. All further steps consider the two current digits of our numbers plus the carry-over from the previous step.
-
I like the general idea and concept of the SO-Constructor project very much, even if many team members
+
-
expressed their doubts about the practical benefits (as Urs mentioned above it could be used for
+
-
substance (e.g. drug) encapsulation. I'm not sure, but I think that one may also use the whole thing
+
-
for detection and localization purposes (e.g. of toxic substances)). As others pointed out already,
+
-
overall feasibility, especially the expected difficulties in connecting the different modules, could
+
-
be a drawback here. Dominic, Giorgia and Herve have really elaborated an excellent model, but to me it
+
-
seems to be very complex and I don't know if we could manage to set the whole thing up in time (on the
+
-
other hand this does not seem to be a general concern because of the "intermediate results"). But
+
-
since my knowledge of (applied) molecular biology is very limited and I don't know how (non-)volatile
+
-
the counter circuit is, my personal feasibility estimation stands on thin soil.
+
-
'''Hervé:'''
+
If you add two numbers with your pocket calculator or your computer, the underlying principle is the same. The only difference is that electronical devices normally work with binary numbers instead of decimal ones. The digits are then only 0 and 1 instead of 0,1,2,...,8, and 9. A half-adder device does the first addition step in an electronical adder;
-
  The presentations made on Thursday had a different profile in terms of details and analysis.
+
it can add two binary input values, the least significant bits of the two numbers. It has also two binary outputs, the sum value S and a carry out C. Two half-adders can be combined to a full-adder, which can be used for the computation of the other (higher valued) bits.
-
It is obvious that the constructor group had focused its energy on the feasibility and the
+
-
options available to circumvent the problems that will arise during the development of this project.  
+
-
It is also clear that we refused to present the details about all these options because we wanted
+
-
to discuss about the concept only. I would recommend people having some doubts about the feasibility
+
-
to check the detailed information available on the wiki. Concerning the usefulness, I do think that
+
-
both projects are extremely useful and I have some problems to understand that people are questioning
+
-
the usefulness of the constructor bacteria project (sorting and purification is a key issue for biotech
+
-
companies for example).In order to make the appropriate choice, I would still need more information
+
-
about the availability of the modules involved in the "thing" project. Do we really have the repressors
+
-
and activators required for this project? Which ones are we gonna use? Considering that it is dificult to
+
-
have activators and repressors with the same "strenght", how could this affect the model and the
+
-
feasibility of the "thing" project? It is really interesting to notice that people have better feeling
+
-
about the feasibility of this project (compared to the constructor bacteria) even though the biology
+
-
part (which is, in the end, the core and working part of the project)has been more or less skipped
+
-
during the "thing" presentation.Regarding the concept of the synthetic biology, I have to agree
+
-
that the "thing" project sounds much more appropriate for this kind of competition. This would be
+
-
in the end the criteria that would push my vote into this project (after a deeper analysis of the
+
-
feasibility and availability of the needed activators and repressors).If we decide to go for this
+
-
project we can of course reduce the risk factor by taking different activator - repressor candidates
+
-
and maybe trying 2 or 3 combinations that have passed through the modelization test.
+
-
'''Christophe:'''
+
A half adder can be constructed from two simplier well-known electronical devices: an XOR gate (the sum value S) and an AND gate (the carry out):
-
Herve, we have not looked for actual repressors/activators because we believe that we should first concentrate
+
-
on the design, at the "functionality" level so to say. Now that that part is more or less clear, well yes, you are
+
-
right, we should start looking at the implementation. And when I say "we", that's everybody, and in particulary you
+
-
and those who have more experience in the lab. I just had a quick look at pubmed, and i found a paper that
+
-
mentions a protein ("TyrR") that acts as repressor and activator (see ref below). Another potential protein is
+
-
"Cra", that can activate or repress depending where it binds to the DNA. Maybe we can work with a fusion
+
-
protein from an activator and a repressor. Maybe we can solve the duality by using an activator that is required for
+
-
the expression of genes 1/3 but represses genes 2/4, that are otherwise expressed constitutively, by placing its
+
-
binding site at a position that overlaps with the polymerase binding sites, etc...
+
-
What are *your* suggestions? Can you look into that issue? Don't you think we can solve that problem?
+
-
'''update''': maybe there is a trivial solution to this problem: we could simply have *both* a repressor and an activator,
+
-
controlled by the same promoter (i.e. heat shock promoter by hand, cell cycle promoter, repressilator) in an operon
+
-
type of scheme. The repressor and activator would target respectively g2/g4 and g1/g3. g2/g4 would have a constitutive
+
-
promoter that is suppressed by the repressor, while g1/g3 would require the activator for expression?!?
+
 +
    A              A
 +
    ^              ^
 +
  1| 1 0        1 | 0 1
 +
  0| 0 1        0 | 0 0
 +
    +-----> B      +----> B
 +
      0 1            0 1
 +
 +
  S = A XOR B    C = A AND B
-
Refs: [http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?cmd=Retrieve&db=PubMed&list_uids=1943694&dopt=Citation TyrR protein of Escherichia coli and its role as repressor and activator.]
+
The sum output S and the carry out C are exactly the values needed for our system. The resulting system architecture is:
-
[http://jb.asm.org/cgi/reprint/178/12/3411?view=reprint&pmid=8655535 The catabolite repressor/activator (Cra) protein of enteric bacteria]
+
-
'''Giorgia:'''
+
[[image:ETH_System_Architecture.png|center| |system architecture]]
-
Although I like our baby very much :-), I must agree with Dominic and Hervé that "the thing" would possibly be a 
+
-
conceptually  more appropriate project than ours.
+
-
Speaking of usefulness, I think both “the thing” and the “constructor x” could turn up to be very useful, so that's not
+
-
really my point. What I am afraid about is that even the model looks perfect the implementation of the thing in the  real
+
-
world would be very tricky. As Dominic stated during our presentation, we introduced the most complicated variant of our
+
-
concept. Therefore, many could have had the impression that feasibility is low. However, we looked for alternatives and made
+
-
up some easier ways to implement each module. Moreover, debugging in this project is possible for each module, what would 
+
-
ensure having some result to present (that would also be nice!).
+
-
It is also my opinion that the presentation of “the thing” lacked of important details on biological background and
+
-
implementation. I don't really think Cra would be an option. Since it controls the expression of many genes concerned with
+
-
carbon and energy metabolism, every time that this protein is present in the cell it will affect the status of the cell and
+
-
its behavior. Moreover, cra promoters are also catabolite repressed or activated (e.g. when fructose-1-phosphate is present
+
-
in the cell, then cra activated operons are repressed and vice versa). I think it is very important that activator/repressor
+
-
does not interact with possibly any other gene promoter in the cell, and that promoters regulated by our activator /repressor
+
-
should not be activated by the interaction with other molecules that could be present at any moment in the cell. Also Tyr
+
-
would not be an ideal option because repression is mediated also by tyrosine and other amino acids (e.g. Phe), which 
+
-
concentration in the cell is difficult to assess and regulate. Moreover, TyrR is also responsible for repression/activation
+
-
of transcription of genes responsible for biosynthesis and transport of aromatic amino acids.
+
-
Well, I don’t want to give you the wrong impression: I don’t think implementation of this concept is impossible! I just want
+
-
to point out that this kind of information is very important (at least for me) in order to be able to make a decision...
+
-
=== Counter (aka The Thing)===
+
=== System modeling ===
-
<table width="252" border="1" cellspacing="2" cellpadding="1">
+
According to the system structure, we first decompose our overall system into devices:
-
<tr>
+
* [[ETH2006_xor| XOR Gate]]
-
<td><b>COUNTER</b></td>
+
* [[ETH2006_and| AND Gate]]
-
<td><b>Urs </b></td>
+
* [[ETH2006_iptg| IPTG (Chemical) Sensing]]
-
<td><b>Tamara </b></td>
+
* [[ETH2006_light| Light Sensing]]
-
<td><b>Jonas </b></td>
+
* [[ETH2006_copy| PoPS Duplexer]]
-
<td><b>Zlatko </b></td>
+
The dynamic behavior of each device was modeled by a set of ODEs (ordinary differential equations). The steady-state we are interested in was determined by simulating the system until all the states (concentrations and rates) settled down to rather constant values. This method is not mathematically sound as systems might settle to different steady-states depending on the initial conditions, or the system might regain momentum after almost, but no completely, settling down. The first concern can be adressed by running simulations starting from varying initial conditions and verifying that there is only a single steady-state, the second issue is rather theoretical as this kind of behaviour is rarely found in real systems.
-
<td><b>Giorgia </b></td>
+
-
<td><b>Simon </b></td>
+
-
<td><b>Kristian </b></td>
+
-
<td><b>Herve </b></td>
+
-
<td><b>Dominic </b></td>
+
-
<td><b>Alexander </b></td>
+
-
<td><b>Christophe </b></td>
+
-
<td><b>Robin </b></td>
+
-
</tr>
+
-
<tr>
+
-
<td><b>Usefulness </b></td>
+
-
<td>10</td>
+
-
<td>10</td>
+
-
<td>8</td>
+
-
<td>9</td>
+
-
<td>-</td>
+
-
<td>8</td>
+
-
<td>-</td>
+
-
<td>-</td>
+
-
<td>-</td>
+
-
<td>8</td>
+
-
<td>-</td>
+
-
<td>10</td>
+
-
</tr>
+
-
<tr>
+
-
<td><b>Feasability </b></td>
+
-
<td>6</td>
+
-
<td>7</td>
+
-
<td>8</td>
+
-
<td>7?</td>
+
-
<td>-</td>
+
-
<td>7</td>
+
-
<td>-</td>
+
-
<td>-</td>
+
-
<td>-</td>
+
-
<td>7</td>
+
-
<td>-</td>
+
-
<td>7</td>
+
-
</tr>
+
-
<tr>
+
-
<td><b>Modularity </b></td>
+
-
<td>7</td>
+
-
<td>5</td>
+
-
<td>10</td>
+
-
<td>5</td>
+
-
<td></td>
+
-
<td>8</td>
+
-
<td>-</td>
+
-
<td>-</td>
+
-
<td>-</td>
+
-
<td>9</td>
+
-
<td>-</td>
+
-
<td>9</td>
+
-
</tr>
+
-
<tr>
+
-
<td><b>Coolness </b></td>
+
-
<td>8</td>
+
-
<td>10</td>
+
-
<td>8</td>
+
-
<td>9</td>
+
-
<td>-</td>
+
-
<td>9</td>
+
-
<td>-</td>
+
-
<td>-</td>
+
-
<td>-</td>
+
-
<td>8</td>
+
-
<td>-</td>
+
-
<td>9</td>
+
-
</tr>
+
-
</table>
+
-
=====Additional Comments:=====
+
==== Modular simulation ====
-
'''Urs:'''
+
Modular modeling allows simulation at different detail levels, e.g.
-
From the engineer's point of few a counter like this is of course a crucial brick. As you can take
+
-
the concentration of any substance you like (by transforming it to our input S) and also add for
+
-
every single counter step a specific gene needed for an application this counter can be used
+
-
whereever you want. The big disadvantage is of course that if the counter doesn't work there will be
+
-
no result you can see.
+
-
'''Addition:''' I think the question we have to ask our selves (if the meeting with Randy Rettberg
+
-
doesn't show any results) the following: Do we want to create something very useful that will be
+
-
reused very often and (in combination with the cell division) meet in a nature article
+
-
according to Sven but risk that we fail and come up with no positiv results? Or do we want to create
+
-
something maybe very useful for the industry, which has a couple of parts more or less likely to
+
-
work but will show at least some reactions and results? Both have their pros and cons and in the end
+
-
it is really (as Dominic said on Thursday) about which direction the Synthetic Biology wants or
+
-
should go: Build a biological super computer or create special behaviour out of bacterias.
+
-
'''Christophe:'''
+
* reusable complexes reoccurring in different devices, like
-
About feasibility: i don't agree with much of what has been said here. The counter is made of two
+
** transcription
-
toggle switches. These switches exist in the nature (lambda repressor) and have also been synthetized
+
** translation
-
(Gardner et al., partly also on MIT registry). Now, the only things we need to come up with are A) a way
+
** encymatic reactions
-
of having 4 different types of road blocks, which is, as Sven said, possible using zinc-fingers that
+
* single devices, different variants of same device type, as a basis of decisionmaking
-
target different dna seqs, and B) a way to have S working as an inducer and as a repressor, in a
+
* 2 or several connected devices &rarr; for instance to see which duplexer variant fits better with which AND/XOR gate variant
-
roughly symmetrical manner. And that's all. I am not saying that it is trivial, but seriously, it is
+
* overall system &rarr; to see if everything together still works
-
really doable. And even if we don't manage it to do it for the jamboree, finishing it later could 
+
-
still be academically very rewarding.
+
-
+
-
Bottom line: The difference between the two projects, i guess, is that most of the work in the QS project
+
-
would be at the assembling/tuning of existing parts for a very cool final effect, while in the the counter,
+
-
we would focus the energy of the whole group into realizing a little module that is reliable and reusable. Both
+
-
projects are cool, both teams have done an increadible amount of preparatory work until now and so at this
+
-
point, i would be very excited working on either projects.
+
-
'''Zlatko:'''
+
We have developed such a modular system in MATLAB:
-
A stable counter would be a very nice thing to have. In my eyes this project seems to be a bit more feasible,
+
* the current implementation defines modules at device level (reusable complexes is a pending issue)
-
but maybe that's a misjudgement. The model as elaborated by the group is detailed and the simulation seems to
+
* modules mainly are characterized by number/kind of input and output and can be simulated with an appropriate simulation function
-
be quite promising. On the other hand the "all-or-nothing" scenario makes it a bit risky.
+
* input/output kind: we destiguish between ''concentration'' and ''rate (PoPS)''  
-
+
* the modules have 1-2 inputs/ouptus, for instance 2 inputs/1 ouptut for AND/XOR gate
-
PS: even though I didn't give a 10 for coolness, I do believe that it's a Nature candidate.
+
 
 +
==== Parameter estimation &amp; sensitivity analysis ====
 +
It is known, and we have made the same (sometimes painful) experience that parameter estimation is the most difficult and laborious part of modeling. Most parameters are simply not known, and estimating them sometimes approaches playing dice.
 +
 
 +
One way to address this problem is sensitivity analysis: if we change some parameter, what effect has it on the behavior of the model? The sensitivity matrix S at steady state can be computed with the jacobian matrices of the ODEs with respect to the states (concentrations) and parameters. To be able to compare the results, parameter and state values are normalized, that is, the changes are expressed relative to the unperturbed value.
 +
 
 +
Sensitivity analysis gives clues about
 +
* whether our models behaviour resembles the desired behavior
 +
* which parameters have hardly any effect on the relevant states (they don't have to be considered further and can be fixed to some arbitary value)
 +
* which parameters influence the relevant states significantly and thus deserve further attention
 +
 
 +
==== The role of modeling ====
 +
 
 +
With all the uncertainties and difficulties (such as parameter estimation) the question might raise whether modeling is worthwile at all. Our answer is yes, but one has to think of modeling as an integrated process. It should not be seen as a precursor phase of experiment and synthesis, it is part of the design cycle.
 +
 
 +
After brainstorming and selecting a project, we started with abstract models of the necessary devices on a very schematic level. For instance, we came up with different theoretical models for the XOR and AND gates - without considering biology too much at this early stage. Then we looked for biological systems which resembled one of our models - the literature research was to some extent model driven. We refined the remaining models and simulated the devices for the first time - here, the ODEs and MATLAB joined in. These models helped a lot in deciding which gate variants should be prefered. As we gained knowledge about possible biological implementations, the models where constantly adapted.
 +
 
 +
Important is also the interaction of modeling and experiments. Modeling and sensitivity analysis can suggest where observed difficulties arise and thus guide the experiments that pin down the problem, eventually leading to a solution.
 +
 
 +
=== System deployment ===
 +
 
 +
We will assemble the AND gate plus the XOR gate on two seperate plasmids (pACYC177 and pACYC184 from NEB). In order for our system to be tested we need a special strain expressing lacI and tetR. In our case we plan to use strain DH5αZ1.
-
== External Information ==
+
=== System test procedure ===
-
=== Links ===
+
In order to test the functionality of the gates experimentally, we decided to mimic the signal inputs via two well controllable inducible promoters. This will help us to test the gates under different input conditions and help in determining the limits of our system. As inducible promoters we chose the lactose-inducible promoter (Plac) and the tetracycline-inducible promoter (Ptet). Both promoters are well described in literature and also tested extensively. However, in order to test our system with those two promoters, we will need to use a special e. coli strain, designed our whose genome encodes for the tetR and lacI gene (e.g. DH5αZ1 strain). The two promoters are flanked by unique restriction sites, so that once the gates are tested, these promoters can be easily exchanged by any promoter of interest. Consequently, our gates could be coupled to a number of other promoters that respond to a desired input signal.
-
* [[Modeling and illustration tools]]
+
== [[ETH_2006_Docs_And_Links|Useful Documents & Links]] ==
-
=== Papers ===
+
[[ETH_2006_Docs_And_Links|see here]]
-
[[bulter04]],
+
-
[[atkinson03]],
+
-
[[bates05]],
+
-
[[keiler01]],
+
-
[[suetsugu03]],
+
-
[[sudesh00]],
+
-
[[römling02]],
+
-
[[ross91]],
+
-
[[sutherland01]],
+
-
[[Lai04]],
+
-
[[zogaj01]],
+
-
[[miller01]],
+
-
[[basu05]],
+
-
[[goryachev05]],
+
-
[[you04]],
+

Latest revision as of 10:15, 19 February 2007

ETH Team 2006


standing (L-R): Marco, Alexandra, Arthur, Olga, Dimo, Marko, Robert; in front (L-R):

Franz, Michael



>>>>>>>>>>>> [http://www.zfranz.ch.vu/iGEM/ETH-iGEM-%202006-%20presentation.pdf Download ETH iGEM presentation 2006 as PDF] <<<<<<<<<<<<

>>>>>>>>>>>>> [http://www.fotofranz.ch.vu/igem See pictures of the iGEM Jamboree in Boston] <<<<<<<<<<<<<

>>>>>>>>>>>>> [http://ftd.de/forschung/154366.html Read article in Financial Times Deutschland: "Eins plus eins gleich Grün" (german only)] <<<<<<<<<<<<<



Adding numbers is easy, isn't it? 1234 plus 5678, for example, is 6912. But how do engineers add binary numbers instead of decimal ones? And how, in the end, can this be done by a living cell? We, the members of the ETH Zurich 2006 iGEM team, are currently working on these questions, whereas the last one seems to be not trivial.

What the addition of numbers has to do with pattern recognition, how our model and the mathematical analysis look like, and how the experiments are realized will be explained on these wiki pages. We wish you a pleasant time with our pages. Enjoy it!



Contents

Coordination

TODOs

Modeling

  • Parts Model the whole System with Sensing, PoPS duplexer and Half adder (Marco and Franz) -- probably not
  • Model whether a different strength of input is necessary for the AND and XOR Gates (Marco)
  • Finish modeling the second AND Gate and find a biological way to implement it and write the DNA and order it (Marco and Robert) -- probably not
  • Bring model parameter up to date & update simulation results/senisitivity analysis (Marco)

Lab

Responsible: Robert for the preparatory experiments, Olga for the assembly and testing of the gates.

  • Read the literature on the XOR and AND Gates, check carefully for strains needed and compatibility of the parts (Who?)
  • Prepare a protocol for parts assembly (Olga)

Documentation

Responsible: Alexandra for the registry, Arthur for the Wiki.

  • enter lab experience report to registry
  • Make a drawing of the DNA to have an overview of which parts will be consecutively on the same DNA piece (Alexandra) (this is part of the #System deployment section --Ajk)
  • Revise images & graphics (Marco):
    • correct errors
    • unify symbols
    • extract missing ones from slides, see here

Presentation/Poster and PR

Responsible: Franz for the presentation, Dimo for PR/Poster

  • design and write the final presentation (with LaTex beamer class) IN PROCESS

Structure:

1. Introduction of the team and ETH Zurich and of the half-adder idea - about 3 min

2. Engineering Part - about 9 min

3. Biological part - about 8 min

(4.) Questions from the audience - 10min (I think, Marco (modelling) and Marko (biology) should also be ready to answer questions)

Schedule

Available as Google Calendar: [http://www.google.com/calendar/render?cid=pqi8ni6gnfj5r3o0np0h4smrr4@group.calendar.google.com iGEM 2006 ETH Zurich]

past
see here
16.11.
Jamboree wrap up (with T-Shirts!), 5pm at CNB seminar room

Team members

Michael Friedmann Dimo Brockhoff Franz Zürcher
Olga Nikolayeva Alexandra Choutko Arthur Korn
Robert Schütz Marco Terzer Marko Jovanovic

Finding a Project

Finding a project to work on is not easy. Not because it is hard to find interesting projects but because there are too many of them. In the first weeks we did a lot of brainstorming including thoughts about the projects' feasibility. You can find a list of ideas here.

During the weeks, we decided to split up the whole team into two groups. Each group proposed a project after these two weeks of separated work:

After the proposals, we decided to further pursue the half adder project idea.

Design process

System behavorial specification

  1. Write something with a chemical on a petri plate (like ETH for example)
  2. Let Bacteria grow uniformly on the plate
  3. Expose the plate to a picture (black and white) of the same pattern
  4. Result:
    • Bacteria gets green when pattern on the plate and picture match (light and chemical)
    • Bacteria does not express fluorescent protein when pattern on the plate and picture match (no light and no chemical)
    • Bacteria gets red when pattern on the plate and picture do not match
           light   no light
chemical     A         B
no chemical  B         C

The outputs can be reported by fluorescent proteins, the mapping of states to outputs is arbitary, our choice is:

A: green
B: red
C: no fluorescence


An experiment in the lab could for instance look like this:


pattern experiment


or like this:


eth experiment

Considering the green and the red output as being separate, the logic mapping the input states to the output states is AND for the GFP and XOR for the RFP. Together they amount to a half adder logic.

The whole system is only considered at it's steady state, dynamic processes are only of minor interest.

System structure

The whole process can be brought into a common input, logic, output form:

[light sensing]----->[       ]-->[reporter A]
                     [ logic ]
[chemical sensing]-->[       ]-->[reporter B]

As it turns out, a [http://en.wikipedia.org/wiki/Full_adder half-adder] can be used as logic part. To understand what a half-adder is, let us first have a brief look at how we add numbers by hand.

If we add two (large) numbers, we usually start with the least significant digits and add these two digits:

  1234
+ 9684
------
 ....8

In the example, the digit's sum is smaller than 10. Thus, we do not need to keep the carry-over in mind (it is zero in this case). For the second digit, the sum is 11 and we have to memorize the carry 1 and so forth:

  1234       1234       1234      1234
+ 9684     + 9684     + 9684    + 9684
   1                   1
------     ------     ------    ------
 ...18      ..918      .0918     10918

In general, each addition step produces the sum, consisting of the current digit of the sum and the carry digit. The only difference between the first and the other steps are the inputs: When the addition starts, there is no carry bit. The inputs are the two least significant digits of our two numbers. All further steps consider the two current digits of our numbers plus the carry-over from the previous step.

If you add two numbers with your pocket calculator or your computer, the underlying principle is the same. The only difference is that electronical devices normally work with binary numbers instead of decimal ones. The digits are then only 0 and 1 instead of 0,1,2,...,8, and 9. A half-adder device does the first addition step in an electronical adder; it can add two binary input values, the least significant bits of the two numbers. It has also two binary outputs, the sum value S and a carry out C. Two half-adders can be combined to a full-adder, which can be used for the computation of the other (higher valued) bits.

A half adder can be constructed from two simplier well-known electronical devices: an XOR gate (the sum value S) and an AND gate (the carry out):

   A               A
   ^               ^
  1| 1 0         1 | 0 1
  0| 0 1         0 | 0 0
   +-----> B       +----> B
     0 1             0 1

  S = A XOR B    C = A AND B

The sum output S and the carry out C are exactly the values needed for our system. The resulting system architecture is:

system architecture

System modeling

According to the system structure, we first decompose our overall system into devices:

The dynamic behavior of each device was modeled by a set of ODEs (ordinary differential equations). The steady-state we are interested in was determined by simulating the system until all the states (concentrations and rates) settled down to rather constant values. This method is not mathematically sound as systems might settle to different steady-states depending on the initial conditions, or the system might regain momentum after almost, but no completely, settling down. The first concern can be adressed by running simulations starting from varying initial conditions and verifying that there is only a single steady-state, the second issue is rather theoretical as this kind of behaviour is rarely found in real systems.

Modular simulation

Modular modeling allows simulation at different detail levels, e.g.

  • reusable complexes reoccurring in different devices, like
    • transcription
    • translation
    • encymatic reactions
  • single devices, different variants of same device type, as a basis of decisionmaking
  • 2 or several connected devices → for instance to see which duplexer variant fits better with which AND/XOR gate variant
  • overall system → to see if everything together still works

We have developed such a modular system in MATLAB:

  • the current implementation defines modules at device level (reusable complexes is a pending issue)
  • modules mainly are characterized by number/kind of input and output and can be simulated with an appropriate simulation function
  • input/output kind: we destiguish between concentration and rate (PoPS)
  • the modules have 1-2 inputs/ouptus, for instance 2 inputs/1 ouptut for AND/XOR gate

Parameter estimation & sensitivity analysis

It is known, and we have made the same (sometimes painful) experience that parameter estimation is the most difficult and laborious part of modeling. Most parameters are simply not known, and estimating them sometimes approaches playing dice.

One way to address this problem is sensitivity analysis: if we change some parameter, what effect has it on the behavior of the model? The sensitivity matrix S at steady state can be computed with the jacobian matrices of the ODEs with respect to the states (concentrations) and parameters. To be able to compare the results, parameter and state values are normalized, that is, the changes are expressed relative to the unperturbed value.

Sensitivity analysis gives clues about

  • whether our models behaviour resembles the desired behavior
  • which parameters have hardly any effect on the relevant states (they don't have to be considered further and can be fixed to some arbitary value)
  • which parameters influence the relevant states significantly and thus deserve further attention

The role of modeling

With all the uncertainties and difficulties (such as parameter estimation) the question might raise whether modeling is worthwile at all. Our answer is yes, but one has to think of modeling as an integrated process. It should not be seen as a precursor phase of experiment and synthesis, it is part of the design cycle.

After brainstorming and selecting a project, we started with abstract models of the necessary devices on a very schematic level. For instance, we came up with different theoretical models for the XOR and AND gates - without considering biology too much at this early stage. Then we looked for biological systems which resembled one of our models - the literature research was to some extent model driven. We refined the remaining models and simulated the devices for the first time - here, the ODEs and MATLAB joined in. These models helped a lot in deciding which gate variants should be prefered. As we gained knowledge about possible biological implementations, the models where constantly adapted.

Important is also the interaction of modeling and experiments. Modeling and sensitivity analysis can suggest where observed difficulties arise and thus guide the experiments that pin down the problem, eventually leading to a solution.

System deployment

We will assemble the AND gate plus the XOR gate on two seperate plasmids (pACYC177 and pACYC184 from NEB). In order for our system to be tested we need a special strain expressing lacI and tetR. In our case we plan to use strain DH5αZ1.

System test procedure

In order to test the functionality of the gates experimentally, we decided to mimic the signal inputs via two well controllable inducible promoters. This will help us to test the gates under different input conditions and help in determining the limits of our system. As inducible promoters we chose the lactose-inducible promoter (Plac) and the tetracycline-inducible promoter (Ptet). Both promoters are well described in literature and also tested extensively. However, in order to test our system with those two promoters, we will need to use a special e. coli strain, designed our whose genome encodes for the tetR and lacI gene (e.g. DH5αZ1 strain). The two promoters are flanked by unique restriction sites, so that once the gates are tested, these promoters can be easily exchanged by any promoter of interest. Consequently, our gates could be coupled to a number of other promoters that respond to a desired input signal.

Useful Documents & Links

see here

Personal tools
Past/present/future years