2020(S10) Lecture:week 8: Difference between revisions

From OpenWetWare
Jump to navigationJump to search
(New page: {{Template:20.20(S10)}} <div style="padding: 10px; width: 670px; border: 5px solid #FFCC66;"> =<center>Week 8 Tuesday</center>= ==Welcome Back Project Status Report== * Brief report of eac...)
 
 
(8 intermediate revisions by the same user not shown)
Line 5: Line 5:
* Brief report of each team's project status.
* Brief report of each team's project status.


 
==Challenge: <font color = blue> Models, Simulations and Magic</font color>==
==Challenge: <font color = blue> Parts</font color>==
===<font color = blue>Equations that describe and predict</font color>===
==Part 1: <font color = blue>Poetic Parts</font color>==
We spent the week before the break considering an intellectual framework for building complex genetic circuits. The abstraction hierarchy, inspired by Mead and Conway's insanely successful one for VLSI, offered a means of decoding complex systems by considering its underlying devices, and the parts within the devices.
This challenge was inspired by This American Life [http://www.thisamericanlife.org/Radio_Episode.aspx?episode=354 #354: Mistakes Were Made]<br>
<br style="clear:both" /><center>[[Image:Hierarchy def.png]]
 
[[Image:Abstraction redrawn.png]]</center>
Consider the content of [http://www.poets.org/viewmedia.php/prmMID/15535  ‘This is Just to Say”] a poem by William Carlos Williams
For example, we build by knowing that DNA encodes proteins (= parts), proteins can be used to elicit particular cellular responses (=devices), and the responses can be rationally daisy-chained to perform as programmed (= systems) --at least that's the hope.  
 
Today we'll consider a complementary approach to understanding a system, namely the modeling and simulation of its behavior. Models play an important roll in all mature engineering disciplines, and simulations can offer quick feedback on how well a system works (or doesn't!). Even when imperfect, the building of a model can uncover limits of our knowledge and the design. First we'll model and simulate a genetic inverter and then you'll give an oscillator a go. These will be stochastic models for behaviors of single cells. We'll consider how to model multicellular behavior once we have these simpler systems in hand.<br>
====Poem 1====
Here are the files you'll need for today:
 
*[[Media:Simple repressilator sim 2010 03 30.docx]]
I have eaten<br>
*[[Media:EQ Get Next States.m]]
the plums<br>
*[[Media:Stochastic sim.m]]
that were in<br>
*[[Media:Calculate Sum Of Avals.m]]
the icebox<br>
and which<br>
you were probably<br>
saving<br>
for breakfast<br>
Forgive me<br>
they were delicious<br>
so sweet<br>
and so cold<br>
 
The poem is often taught in poetry classes and often spoofed. Consider, for instance, these 2 spoofs by [http://www.radio-sweethearts.com/2008/04/21/public-radio-poetry-vol-3-william-carlos-williams-on-this-american-life/ Kenneth Koch]:<br>
 
====Poem 2====
 
Last evening<br>
we went dancing<br>
and I broke your leg<br>
Forgive me<br>
I was clumsy and<br>
I wanted you here<br>
in the wards<br>
where I am the doctor<br>
 
====Poem 3====
 
I chopped down the house that you had been saving to live in next summer.<br>
I am sorry, but it was morning, and I had nothing to do<br>
and its wooden beams were so inviting.<br>
 
 
And one more spoof from the blog [http://somewhereinthesuburbs.wordpress.com/2008/04/21/this-is-just-to-say/ somewhere in the suburbs]<br>
 
====Poem 4====
 
I have dried<br>
the shirt<br>
made of 100% cotton<br>
that was on your floor<br>
and which<br>
you were probably<br>
planning<br>
to air dry<br>
Forgive me<br>
if you had sorted<br>
your own laundry<br>
it would not be<br>
so short<br>
and so small<br>
 
If you wanted to write your own spoof of the William Carlos Williams poem, you might begin by comparing the structure of these four poems. As a starting point they can be broken into 5 elements, namely
* 2 part situation 
*“forgive me,” and
* 2 part explanation.
 
For each poem, these elements are:
 
{| border=1px
|'''Situation  (part 1)'''
|'''Situation (part 2)'''
|'''Forgive me'''
|'''Explanation (part 1)'''
|'''Explanation (part 2)'''
|--
| I have eaten the plums that were in the icebox
| and which you were probably saving for breakfast
| Forgive me
| they were delicious
| so sweet and so cold
|--
| Last evening we went dancing
| and I broke your leg
| Forgive me
| I was clumsy
| and I wanted you here in the wards where I am the doctor
|--
| I chopped down the house
| that you had been saving to live in next summer.
| I am sorry,  
| but it was morning, and I had nothing to do
| and its wooden beams were so inviting.
|--
| I have dried the shirt made of 100% cotton that was on your floor
| and which you were probably planning to air dry
| Forgive me
| if you had sorted your own laundry
| it would not be so short and so small
|}
 
===Mix & Match Poetry===
Now we can try to swap these poetic elements to see what interesting and clever spoofs we write. How about:
{| border=1px
|'''Situation  (part 1)'''
|'''Situation (part 2)'''
|'''Forgive me'''
|'''Explanation (part 1)'''
|'''Explanation (part 2)'''
|--
| I have eaten the plums that were in the icebox
| and I broke your leg
| Forgive me
| but it was morning, and I had nothing to do
| and I wanted you here in the wards where I am the doctor
|}
 
That seems to work but is it better? Let's try again:
 
{| border=1px
|'''Situation  (part 1)'''
|'''Situation (part 2)'''
|'''Forgive me'''
|'''Explanation (part 1)'''
|'''Explanation (part 2)'''
|--
| I chopped down the house
| and which you were probably planning to air dry
| Forgive me
| they were delicious
| it would not be so short and so small
|}
 
Well shoot, that's horrible. For one thing: It doesn't say anything understandable---this can be broadly described as a problem of '''functional compostion'''. For another thing: the connection between the different elements is, well, "awkward" at best---this can be broadly described as a problem of '''physical composition'''. If physical and functional composition of poems were working perfectly then every part would grammatically connect to the ones that flank it, and the meaning of the connected pieces would be interpretable at worst and clear at best.
 
==Part 2: <font color = blue>Genetic Parts</font color>==
 
The physical and functional assembly of the poetic parts can be mapped to biological engineering once we define what a genetic "part" is. Let's start by extending what we did with the William Carlos Williams poem, namely let's consider a few natural genetic compositions, see what common elements compose them, and then try to bin these so we might compose new genetic elements by mixing and matching parts.  
 
The bacterial lac operon is one we're already familiar with from our conversation earlier in the term.
[[Image:Lac operon1.png|600 px]]
 
There are several genes encoded by this composition. LacI is made and we can see it's flanked by a promoter and a terminator. Lac Z, Y, and A are also made and they are flanked by a promoter + an operator on one end and a terminator on the other. So some genetic parts we might consider naming are:
*promoter
*operator
*protein-coding gene
*transcriptional terminator
 
Recombinant DNA technology gives us great power to move pieces of DNA around but it doesn't answer all the questions we might have about the resulting composition. For instance, are promoters/operators/genes and terminators all the parts we need to write a genetic program. Would the promoter that's in front of LacI make sense in front of LacZ, Y, and A? Is there something important about the junction of the parts?
An introduction to systematic examination and nomenclature of genetic parts, watch Device Dude and Systems Sally's introduction to [http://biobuilder.org/part.html Parts]
 
==Part 3: <font color = blue> The Registry of Standard Biological Parts</font color>==
The animation ends with a screen shot from the [http://bbf.openwetware.org/ BioBricks Foundation] a not-for-profit organization that "encourages the development and responsible use of technologies based on BioBrick™ standard DNA parts that encode basic biological functions." BioBricks™ represent one kind of standard biological parts, standardized to enable reliable physical composition.
Just as we mixed and matched poetic elements, here are some mixed and matched genetic elements made from BioBrick™ parts.  
<center>
[[Image:BBa_I13603.png]]<br>
[[Image:BBA-I13521.png]]<br>
[[Image:Be109BBa M30010.jpg]]<br>
[[Image:BBa_J44011.png]]<br>
</center>
 
Just as we could identify "forgive me"-ish elements in the "this is just to say poems" we can see common elements in these genetic compositions: the green arrow element which is = a promoter, but which comes in different flavors (I13452, R0040 or R0011), the red stop signs = transcriptional terminators (B0010, B0012).
 
The part numbers as well as the DNA itself are collected at the [http://parts.mit.edu/registry/index.php/Main_Page Registry of Standard Biological Parts].
 
For your final project in this class, you will enter a part into the registry. We'll look at some good parts and some good documentation in class so you can model your work on those examples.


==Before tomorrow's studio time==
==Before tomorrow's studio time==
Line 176: Line 22:


=<center>Week 8 Studio</center>=
=<center>Week 8 Studio</center>=
==Part 1:<font color = blue>Model and Simulation for a Toggle switch</font color>==
Extending the lesson we started yesterday, here are the files you'll need for today:
*[[Media:Simple toggle sim 2010 03 31.docx]]
*[[Media:Stochastic sim 2.m]]
*[[Media:EQ Get Next States.m]]
*[[Media:Calculate Sum Of Avals.m]]
==Part 2:<font color = blue>Project work time</font color>==
Let's get busy working on the details of these projects!
=<center>Week 8 Thursday</center>=
<center>''“Faith is a poor substitute for reason”'' Thomas Jefferson</center>
==Part 1: <font color = blue> Eau d'coli test/debug</font color>==
==Part 1: <font color = blue> Eau d'coli test/debug</font color>==
<center>
<center>
Line 187: Line 45:
*Finally, look again at the device-level system diagram.  Is there anything about the system's design that makes testing and debugging easier or harder than it might be otherwise?  Would you like to change any aspects of the system design to make testing and debug easier?
*Finally, look again at the device-level system diagram.  Is there anything about the system's design that makes testing and debugging easier or harder than it might be otherwise?  Would you like to change any aspects of the system design to make testing and debug easier?


==Part 2: <font color = blue>Data-driven Decision-making</font color>==
Consider once more the Melbourne 2007 iGEM project. In a series of questions at the end of [http://parts.mit.edu/igem07/jam07media/Jam07_Melbourne.mp4 their presentation], the team gets asked about any changes to the gas vesicles device that might allow gas-filled cells to become even more buoyant. Their answer speaks to some scientific work others have done to understand the vesicle-encoding operon, research that has shown at least one gene in the operon is a negative regulator. By deleting that gene, the Melbourne team thinks they might make their cells even more buoyant. '''If you and your team were the Melbourne team, what would you do with this information?''' <br>
First let's review one technical advance that opens a number of options for you, namely [http://www.biobuilder.org/dnasynthesis.html DNA synthesis.]
Then as a class we'll consider some options--weighing these (or others) in terms of their associated cost (both time and money).
*Use the entire gas vesicle operon to get the basic Coliform system working then tweak the system later to improve it.
*Wait to assemble your system until you can perform experiments to know more about each gene in the operon.
*Divide the team in half, with some launching into the project with the DNA as is, and others studying it and refining it.
*Spend one week in the library to read all you can about these vesicles and then decide.
*Place a DNA synthesis order for the full operon (6 kilobases) as well as every single gene knockout and double gene knockout.
===Mapping these ideas to your project===
Now it's time to look at the list of devices you have identified as part of your project (some of you may have a full list of needed devices and some of you will have only a partial list, in which case you'll have to consider these ideas now and then revisit them when your device list is complete). What might factor into the cost and time of assembling the devices into your working system? Do you know all you need to know about how they work? Are there easy ways to find out more? Do the devices already exist or will you have to make them yourself? You might want to make a chart that lists your degree of confidence in each device, where confidence is tempered by its cost/time/source/description and perhaps safety/security concerns...something we will return to next week. <br>
Generate a list or table that might be useful as part of your [[20.20(S10): Technical Specification Review| Tech Spec Review]] next week.
==Part 3: <font color = blue>Project work time</font color>==
Let's get busy working on the details of these projects!
=<center>Week 8 Thursday</center>=
<center>''“Faith is a poor substitute for reason”'' Thomas Jefferson</center>
As you hone in on the details of your projects, your team should plan ways to validate the system's operation and ways to learn from its glitches. We have two quick challenges for you today. The first illustrates that even the "best" answers you can offer that are consistent with all available data remain tentative, that the answer is either strengthened or revised by additional data and that all interpretations are subject to personal biases, human values and the various ways we all think about the world. The second challenge puts you midstream in a flawed design and requires that you consider the modes of failure to debug/troubleshoot the problem. <br>
We will spend '''only 20 minutes on these challenges''' and then you and your team can use the rest of today's lecture time to prepare for next week's [[20.20(S09): Technical Specification Review| Tech Spec Review.]]
==Challenge 1: <font color = blue> The check's in the mail </font color>==
This challenge is adapted from Judy Loundagin's lesson, [http://www.indiana.edu/~ensiweb/lessons/chec.lab.html here].
# One member of your team should serve as scribe (with notebook sheet to be provided). Another should be spokesperson (see item 7, below).
# Each team should get one envelope that is filled with fictional checks. Do not look at the checks yet. All envelopes have the same checks.
# Remove and examine '''4 checks only.'''
# Discuss a plausible scenario which involves those checks.
# Once your group has agreed on a reasonable scenario that accounts for the checks, and the scribe has written it down, then you can draw '''4 more checks from the envelope.''' As tempting as they are, the unchosen checks must stay in the envelope, unexamined.
# Reconsider your initial scenario to include the information you can glean from all 8 of the checks. 
# We will take 1 minute to hear from each team. The spokesperson should detail
*the content of the first 4 checks,
*the way your team considered their content and
*the initial conclusion you drew
*the details of the next 4 checks and
*the revisions you made to the scenario to accommodate the information. <br>
Finally, the spokesperson should say '''what kind of check they would expect to see''' in the envelope if their scenario is correct '''OR what kind of check would blow their ideas out of the water''' and demand a full re-write of their explanation.
==Challenge 2: <font color = blue> Soap Stress </font color>==
[[Image:CompressionalStress.png|thumb|left|Compressional stress on a cube]]
[[Image:TensionalStress.png|thumb|left|Tensional stress on a cube]]
[[Image:ShearStress.png|thumb|right| Shear stress on a cube]]<br>
This challenge is adapted from one described at [http://www.teachengineering.com/ teachengineering.org]. We will skip the preliminary descriptions of [http://scign.jpl.nasa.gov/learn/plate5.htm plate tectonics] and just remind you of three stresses that give rise to deformation: compression, tension and shearing forces.
[[Image:Brokensoap.png|center|200pxl|sample of soap packaging and damage]]
# Begin by looking at how the packaged soap is breaking during shipment from the factory to the distributor (a sample of the broken soap will be available for you to look at). Decide as a team which kind of stress could be leading to this kind of damage. '''Pick only one kind''' (i.e. not a combination of tension and shear) and rate your confidence in that choice on a scale of 1-10 (1 = we had to pick something so we picked this, 10 = I'd bet my house on it)
# Now start counting costs to analyze and fix what you believe to be the failure mode.
#* if you'd like to stress an unbroken soap bar, each bar costs $1
#* if you'd like to use paper to wrap each bar of soap, each sheet of paper costs $0.01
#* if you'd like to use a small piece of cardboard to line each bar of soap, each piece of cardboard costs $0.05
#* if you'd like to use larger sheets of cardboard to line each 12 pack of soap, each large sheet costs $0.50
<br>
'''In 5 minutes''', your team will be asked
*which of the three stresses you believe could be breaking the bars of soap
*how confident you are with that choice
*what you'd propose as the best way to fix the problem
*how much you spent to arrive at that recommendation and what your proposed solution will cost
*and finally if you are more or less confident in the source of stress that's breaking the soapbars after this quick round of failure analysis, and debugging.
Be sure to wash your hands before you touch your eyes if you've been breaking soap to test it.
==Mapping these challenges to your project==
==Mapping these challenges to your project==
There is no such thing as either complete knowledge or flawless design. And if you believe, as Henry Petroski does, that "...the central goal of engineering is still to obviate failure, and thus it is critical to identify exactly how a structure may fail." (pg 195 in [http://www.amazon.com/Engineer-Human-Failure-Successful-Design/dp/0679734163 To Engineer is Human]), then you and your team will dedicate effort  
There is no such thing as either complete knowledge or flawless design. And if you believe, as Henry Petroski does, that "...the central goal of engineering is still to obviate failure, and thus it is critical to identify exactly how a structure may fail." (pg 195 in [http://www.amazon.com/Engineer-Human-Failure-Successful-Design/dp/0679734163 To Engineer is Human]), then you and your team will dedicate effort  
*to collecting relevant data that validates or disproves the ideas in your own project and  
*to collecting relevant data that validates or disproves the ideas in your own project and  
*to anticipating failure modes so debugging your design is trivial rather than backbreaking. <br>These ideas of validation and debugging should be included in your Tech Spec Review, at least a first go at them.
*to anticipating failure modes so debugging your design is trivial rather than backbreaking. <br>These ideas of validation and debugging should be included in your Tech Spec Review, at least a first go at them.

Latest revision as of 11:34, 31 March 2010

<html> <style>#en2020 a {color:black;}</style> </html>

Week 8 Tuesday

Welcome Back Project Status Report

  • Brief report of each team's project status.

Challenge: Models, Simulations and Magic

Equations that describe and predict

We spent the week before the break considering an intellectual framework for building complex genetic circuits. The abstraction hierarchy, inspired by Mead and Conway's insanely successful one for VLSI, offered a means of decoding complex systems by considering its underlying devices, and the parts within the devices.


For example, we build by knowing that DNA encodes proteins (= parts), proteins can be used to elicit particular cellular responses (=devices), and the responses can be rationally daisy-chained to perform as programmed (= systems) --at least that's the hope. Today we'll consider a complementary approach to understanding a system, namely the modeling and simulation of its behavior. Models play an important roll in all mature engineering disciplines, and simulations can offer quick feedback on how well a system works (or doesn't!). Even when imperfect, the building of a model can uncover limits of our knowledge and the design. First we'll model and simulate a genetic inverter and then you'll give an oscillator a go. These will be stochastic models for behaviors of single cells. We'll consider how to model multicellular behavior once we have these simpler systems in hand.
Here are the files you'll need for today:

Before tomorrow's studio time

If there are outstanding issues related to the system you're working on for your project be sure everyone on your team knows how you'll solve the issue(s) and make a plan to come to studio tomorrow with materials for finishing the system overview and getting good work done on the device list and the timing diagram.

Week 8 Studio

Part 1:Model and Simulation for a Toggle switch

Extending the lesson we started yesterday, here are the files you'll need for today:

Part 2:Project work time

Let's get busy working on the details of these projects!

Week 8 Thursday

“Faith is a poor substitute for reason” Thomas Jefferson

Part 1: Eau d'coli test/debug

Aye yay yay! Won't we ever get away from this Eau d'E coli project? Not yet! Take a close look at the device-level system diagram. You can't see all the underlying BioBrick parts (there are ~24 parts in total). If you were the designer of this system, do you think that the system would work if you just synthesized all the DNA as a single contiguous strand, transformed this new DNA into a cell, and let your genetic program rip!? Or, stated differently, what would be your next step if you tried to get everything working at once, and NOTHING HAPPENED, or, even worse, your engineered DNA killed the cell?

Having a plan for testing and debugging your projects is critical. To help you think about how to develop the best testing and debug plan for your 20.020 projects, spend the next 10' working with your team to outline a testing and debug plan for the Eau d'coli system. Before you get started, designate one person on your team to act as spokesperson. Once the 10' are up, we'll ask each spokesperson for an accurate description of your testing and debug plan. If you're having trouble knowing where to start, you might consider:

  • First, use the device level system diagram to sketch out a timing diagram (use a white board).
  • Second, think about what this iGEM team could have done if they just added all this DNA to the cell, and then nothing happened (no smell, or worse, all the cells died). How would they go about figuring out what aspects of the project might be working, and what other components need to be revised or fixed?
  • Finally, look again at the device-level system diagram. Is there anything about the system's design that makes testing and debugging easier or harder than it might be otherwise? Would you like to change any aspects of the system design to make testing and debug easier?

Mapping these challenges to your project

There is no such thing as either complete knowledge or flawless design. And if you believe, as Henry Petroski does, that "...the central goal of engineering is still to obviate failure, and thus it is critical to identify exactly how a structure may fail." (pg 195 in To Engineer is Human), then you and your team will dedicate effort

  • to collecting relevant data that validates or disproves the ideas in your own project and
  • to anticipating failure modes so debugging your design is trivial rather than backbreaking.
    These ideas of validation and debugging should be included in your Tech Spec Review, at least a first go at them.
Retrieved from "https://openwetware.org/mediawiki/index.php?title=2020(S10)_Lecture:week_8&oldid=403441"