2020(S10) Lecture:week 8

From OpenWetWare
Jump to navigationJump to search

<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

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=402936"