Nomograms for Synbio

I've always really liked nomograms. They're basically a set of axes drawn on a page in such a way that each axis represents one (or more) variables and by drawing lines between the various axes, it's possible to find unknown variables graphically.

One of the most basic nomograms possible simply adds two numbers:
From this simple beginning, it's possible to make other analog computation devices that are much more sophisticated. By using logarithmic axes, you can perform multiplication, since log(x) + log(y) = log(xy).

Nomograms are rather outdated, now that computers can perform numerical calculations much more easily and with far greater accuracy than anyone can measure by hand. The reason I'm looking into nomograms again is because they can be distributed on paper more easily than a computer program, they are relatively intuitive, and they allow very complex systems of equations to be solved by people who don't know math. There are also some iGEM outreach events coming up...

...so we'd like to be able to show people mathematical modelling stuff that's related to synthetic biology, but it's hard to come up with stuff that's interesting, learnable in minutes, and true. I think it's possible to condense some tricky work into a graph:


The above graph shows a setup that could calculate the concentration of a molecule and its isomers given a reaction rate constant (provided the axes were properly scaled). This is a fair amount of work (for the creator of the nomogram) when you could just plug "exp(-k*t)" into a calculator, but it's hard to beat the connect-the-dots simplicity of a nomograph. The other nice thing about this type of graph is that it really emphasizes the fact that it's easy to 'cheat' and start with the desired final answer and work backwards to get inputs... ie, design the system analytically.

Unfortunately, the irreversible isomerization reaction is still rather lame and even with an easy method of calculating it, it's still not particularly exciting. What would be cool would be to get a system of equations that describes an optimization problem and have a graph visually represent design trade-offs (like the triangular graph on this page), but that sounds like it might be too ambitious for me to tackle in a couple of spare hours.

Teleconference

It is not always easy to understand a large group of people speaking into a laptop microphone at the same time.

Context-free grammar (Part 1 of 2)

What are context-free grammars? An abstract definition might say that they're a set of rules allowing for the construction of complex structures consisting of logical parts that can be arbitrarily nested, but I've found that nobody really likes my abstract definitions, so I'll try using an analogy instead.

Consider a freight train hauling three containers (containers A, B, and C):

Let's say that container A can only contain livestock, container B transports liquids, and container C contains manufactured goods. It doesn't matter what type of livestock, liquids, and manufactured goods are transported so long as they fit into their respective categories.

We have just defined a very simple grammar. Within this structure, it is possible to have 'phrases' such as "pigs milk computers" or "cows mercury needles".

A cow-mercury-needle train and pig-milk-computer train collision would be unfortunate.

Both the cow-mercury-needle train and the pig-milk-computer train are examples of the same model of train — an A-B-C train — that happen to be carrying different items in their identical containers. The model of the train can be thought of as one rule (or phrase structure) in the grammar, but it is certainly possible to have other rules.

The analogy gets a bit weird here (yes, weirder than the above image) because context free grammars also allow their containers to contain other trains.

Let's imagine a different model of train, the B-A-Weird train that has a B-container (which must, as before, contain a liquid), an A-container (holding livestock) and a weird container which holds either an A-B-C train or a B-A-Weird train. Now instead of a pig-milk-computer train, it would be possible to have a milk-pig-cow-mercury-needle train where the milk is in compartment B, the pigs are in compartment A and the cow-mercury-needle train from above is all in the weird compartment.

Okay, that's pretty weird, but that's not nearly as strange as being able to put a B-A-Weird train inside the Weird compartment. This could allow us to take the entire train we just discussed and stick it in the last compartment of another B-A-Weird train. Then we could take that train and do the same thing, over and over, as much as we would like. However, at this point the train analogy has lost almost all meaning and is likely confusing matters substantially.

Fortunately, there is a familiar application for context-free grammars that should make more sense now, namely language. By specifying containers in terms of parts of speech instead of cargo, we can construct sentences instead of trains. This is sort of reminiscent of Mad Libs: "the {noun} {past tense verb} the {noun}" would be one example of a sentence structure from a context-free grammar. Amusingly, this is also how Matlab's "why" function manages to produce output such as "The bald and not excessively bald and not excessively smart hamster obeyed a terrified and not excessively terrified hamster."

As before though, things get interesting when sentence structures get put inside of other sentence structures (just as trains... get... er, put inside of other trains). We can expand the definition of nouns to include phrases in the structure "{noun} the {noun} {past tense verb}". This allows phrases such as "man the hamster ate" to be used in place of the simple noun "man". And why not? Anywhere you can refer to a man, you can grammatically refer to a specific man who happened to be eaten by a hamster.

There is a slight problem with this setup in that, as before, things get complicated when structures are continually placed inside other structures. The phrase

"The dog the boy the man the hamster ate raised owned bit the boy the man the hamster ate raised."

is in fact valid using the two rules defined above and can be parsed as:

The (dog the (boy the (man the (hamster) ate) raised) owned) bit the (boy the (man the (hamster) ate) raised).

...meaning the hamster ate the man who raised the boy who owned the dog which bit the boy raised by the man eaten by the hamster.

So... yeah, people don't generally speak like that because of cognitive limits to how many nested levels of information we can keep track of at once. But maybe, you say, this idea of context-free grammar could still be useful for creating different kinds of structure. Some sort of really complex structure that can have parts embedded in other parts in ways that are hard for people to imagine. Perhaps, you hazard, some sort of biological structure.

In this last set of thoughts, you've outlined the general idea behind GenoCAD, a context-free grammar for synthetic biology. It seems to be a good fit at first but, as Andre from the UW iGEM team points out, there are quite a few properties of DNA sequences that it fails to capture. More on this later.

Public lectures and I found my stylus!

Yessssssssssss. That is the sound of me rediscovering my tablet computer's stylus. You don't realize how expensive a piece of plastic can be until you start thinking you'll have to replace one. Fortunately, I don't have to replace one, so here's a celebratory doodle:

Click for larger sketchy drawing!

The iGEM team (next post, I'll stop writing about iGEM in the next post) hosted a public lecture today about synthetic biology. There were a ton of people there which was pretty awesome and various misconceptions about the recent Venter Institute announcement were addressed. I did get the feeling the panel was preaching to the choir a little bit about some issues, but with the number of people there, I'm sure the topic was new to a sizeable group.

In other news, I appear to have pulled a gluteal muscle for no apparent reason. This is not so fun. I would go so far as to recommend against pulling such muscles, in fact!

Let's All Learn About iGEM Software! Yay!

This is one of those posts I wrote for my own benefit, not some hypothetical readership. This will likely be apparent. You have been warned.

I was originally planning on writing about something else and including my standard doodle with this post, but my Google search for reference images seriously grossed me out and I don't have time for that. Instead, here's a post about iGEM software which will force me to do some useful research instead of looking up eye-rending images on Google. Yay!

If you don't know me and are new to this blog here are some explanatory links about iGEM. With that out of the way, what's up with this year's Waterloo iGEM software project? Well, we're working with a BioCompiler concept that roughly translates to: take code, apply genius, extract BioBrick assembly instructions. A compiler, in a computational context, takes code and translates it into equivalent code in a much more primitive language and what we intend to do is an exact analogy of that process for biological systems.

We haven't gotten very far with this design yet, but already there seems to be a canonical example of the goal in the form of the pseudocode "if the concentration of (something) exceeds (value) and the concentration of (something else) is less than (another value) then produce [something]". I wonder how much complexity would be involved in simply translating specifications that meet the above template into assembly instructions; intuitively, I don't feel it should be too excessive, but there is already some possibility for conflicts between the signalling pathway of "something" versus "something else" and this system would already probably be pretty tricky to construct. Following this vague syntax, our working design for the main 2010 project would fit the template "if (something) is present, produce (something else); if the concentration of (something else) is above (constant), produce (yet another thing)". That's an almost trivial piece of code, but it's already pushing the limits of what we can model and what we can construct. Whether this a ringing endorsement of the BioCompiler concept or an outright condemnation, I'm not sure.

The BioCompiler concept is both really exciting and worrisome at the same time. Worrisome, because in order to pursue the BioCompiler idea we'll be discarding work done by the software team of the previous term which sets a bad precedent for continuity. Moreover, this project will definitely not be done before the end of the term, so we'll need to depend on the software team from the opposing stream to continue it. On top of the "sorry I killed you project" factor, it also bugs me that this isn't a project I could conceivably sit down and write myself given a couple weeks. I mean, I realize that it's a good thing that we have an ambitious project that will involve more than myself, and I never had any intention of literally writing the whole software project by myself, but at the same time I like being able to deliver tangible results and this project has no guarantees of delivering those results any time soon. Nonetheless, optimism run high.

Okay. That was all a long diversion because the point of this post was for me to force myself to read and talk about UC Berkeley's 2009 software project. Their project had four main components, all of which are helpfully embodied by silly characters in their documentation. Eugene, the "red-headed stepchild and language", is a formal way of describing BioBrick components. His glasses, Spectacles, are (represents? is? this is where the anthropomorphization of the software modules becomes frustrating linguistically) a tool for visualizing Eugene's data. Kepler is a "Wise Astronomer and Workflow Wizard" which is to say that it's the part of the project concerned with the assembly of parts and it/he actually guides a robot through the assembly process. That was bold and italic because it's that mindblowing. Finally, Clotho (AKA the Hot Green Chick) is a "Greek Goddess and Software Tool". Say what you will about Berkeley's documentation, at least it's memorable (and actually the rest of their documentation is decent as well, including design notes from team members and demo videos of some of the software products).

Anyway, Clotho, yeah. Clotho is an attempt to span the design hierarchy between the parts-level design that Kepler, Eugene, and Spectacles work at and the systems-level and device-level design that engineers like to think at. Actually, upon re-reading the Berkeley page, it appears they believe Kepler, Eugene, and Spectacles operate at the device-level. Huh. It also appears that despite lofty aims at hierarchy-spanning behaviour from Clotho, that module is a simple data management system. It might help you organize your thoughts at varying levels of abstraction, but it certainly won't take ideas written at one level and push them to another. That, I guess, is where we come in.

Alright folks, I'm falling asleep so this is as far as we come today. If you've read this far, I... well I don't know what to think. I'm assuming you haven't read this far. Maybe you cheated and skimmed to the end. In any case, thanks for bearing through it and hopefully everyone learned a valuable lesson about iGEM software. Yay!

Recruitment Meeting

This picture is in no way related to the content of this blog post.

UW iGEM had its recruitment meeting today. It was fun times! But I really need work on my presenting abilities; I find I'm really hit-and-miss in my ability to actually convey information while speaking to groups of people. This doesn't come as a surprise, I was always consistantly bad at "verbal communication" as the elementary school report cards would call it, at least by the crazy perfectionist standards of my youth. Nonetheless, I like to avoid being "that guy that gave that talk that nobody understood" whenever possible.

I find it interesting that the fields I'm working in now, both at iGEM and in co-op terms tend to be the interdiscplinary/academic/cutting-edge-no-one-really-knows-what's-going-on fields that are prone to having miserably unintelligible talks. I've sat through a lot of these talks now and they're fairly painful, so painful at times that it's tempting to simply say that the presenter stood no chance and that the topic was simply too complicated to communicate in the available time. Of course, then I go off and watch some TED talks and realize that you can describe pretty much anything worth describing in twenty minutes if you're just that good.

Postscript: I was just about to post this and was looking through what tags to apply, when I realized I have an existing "Painfully Bad Poetry" tag. We were discussing painfully bad iGEM poetry for some reason or other at today's meeting and, well, I have the tag, so...

iGEM (a haiku)
the title counts as a line
oh shoot, out of room

Okay, this next one's the real haiku, not that that previous one wasn't (also, non-iGEM people, iGEM is pronounced "I gem", which is ironic given its silly capitalization which I've probably ranted about before).

lots of little cells
and biology stuff, woot
will sell soul for sleep

Webpages 'n' Competitions 'n' Stuff

If I haven't been posting a lot lately it's because I've been giving the Waterloo iGEM team wiki a shiny new theme, mulling over the Intelligent Systems Challenge, and going to my actual job.

I don't have much else to report on, although the iGEM forums linked to a really cool story about oil drops which I'm shamelessly reposting here. This experiment is right up there with Millikan's famed oil drop experiment in terms of scientific oil experiments that utterly blow my mind.

IGEM Jamboree 2009

I arrived back in Waterloo from MIT about 15 hours ago now. I'm a little bit behind in school work right now, so I can't really do the Jamboree/conference/competition justice (not that I could ever do it justice in a single blog post), but I thought I'd type up some assorted thoughts anyway...

• Road Trip (1): It's a nine hour drive. A couple of the more experienced members of the team chose to pay for flights instead.
  
• Road Trip (2): Toll roads... everywhere.
  
• MIT vs Waterloo (1): I've had an unhealthy admiration for MIT for a very, very long time so a lot of the people who knew me assumed I'd be disillusioned by this trip.
• MIT vs Waterloo (2): They both have those ugly abstract sculptures that are just beams welded together and painted a single colour; however, MIT's are bigger, blacker, and placed in the open while Waterloo's are small, orange, and pushed off to the side. Lesson: if you're going to have a Big Ugly Statue, you might as well make it Big.

MIT has ugly statues too! Ours are still uglier.

• Hotel (1): The Marriott. Not to be confused with the other gazillion Marriott's in Cambridge.
• Hotel (2): Once we found the Marriott, it was surprisingly swank. I'm more used to hostels and motels, but the Marriott is a genuine hotel.
• Jamboree (1): We missed breakfast on the first day. Never miss breakfast if you want to be alert for six morning lectures on synthetic biology. It's painful.
  
• Jamboree (2): The Osaka team presented their work on gene art; Valencia mock-interviewed themselves about voltage-controlled light-emitting cells (that were controlled using a laptop sound card); Pavia, Wisconsin, and Uppsala Sweden presented various ways of using biology to solve energy/environmental problems.
• Jamboree (3): The lunches provided by MIT catering made up for the lack of breakfast. Never has grilled roast beef and pasta tasted so good (with a side of a bun and a godly brownie).
• Jamboree (4): I saw several talks in the information processing track on Saturday afternoon. I found them more understandable than the morning talks; being fed and interested in the information processing category helped substantially. The Bacterial Decoder project (Illinois) and Satisfiability problem sover (MoWestern Davidson) were particularly cool.
• Jamboree (5): The 4:30 PM timeslot on Saturday had a few interesting-looking presentations. I passed up the chance to see the MIT and Freiburg software presentations to go to the John Hopkins' talk about their Build-A-Genome course.
  
• Poster Session (1): Tom Knight's presence greatly excited a couple members of the team.
• Poster Session (2): I talked to a few groups about their projects. Nobody really discusses modeling.
• Hotel (3): Staff are dressed for Halloween. This is probably the only day when plastic weaponry can be freely brandished in the lobby. Then again, it is the States, so maybe they do allow rifles in hotels.
• Hotel (4): The team from Brussels meets us in the lobby and provide an audience for our practice presentation.
• Hotel (5): No. Cheaper by the Dozen is not a good movie.
• MIT vs. Waterloo (3): The campus is surprisingly dead. I feel like there's some cool stuff lurking around, but without any students around it feels like any other conference center. Also, our section of Cambridge is a ghost town over the weekend.
• Jamboree (6): I didn't see the Alberta presentation, but other members of the team were quite excited by it. They were working on a toolkit for artificial genome construction. This somehow included a "Lego DIY biofab robot". I'm not quite sure how this all worked, but I plan on reading Alberta's wiki soon.
• MIT vs Waterloo (4): Woke up really early to get breakfast on the second day. It was worth it. Bagels, muffins, hard-boiled eggs, yogurt parfait's, fruits... I can't believe they ran out on the first day.

The MIT nerd crossing sign.

• Jamboree (7): Another day, another twelve presentations. Waterloo's own presentation about our chromosome engineering project was an obvious highlight.
• Jamboree (8): Bristol's presentation, which immediately preceded ours, included some pretty cool modeling software. They eventually won the modeling award.
• Poster Session (3): More posters... it's a bit frustrating that they're all spread out, there were a couple of teams that I wanted to talk to that I just never saw.
• Poster Session (4): Technically, I could have found posters by looking up the teams in the provided poster list. I think I lost mine.
• Jamboree (9): the iGEM Canada meeting was quite interesting. It'll be interesting to see how attempts to organize the Canadian teams unfold. There's currently a Facebook group.
  
• Hotel (6): The hotel had no free wifi, but it did have a single room with three computers (the "business center") where I could check email and (more importantly) accept a job offer. Collectively, the iGEM teams hogged the business center.
• Social Event (1): More free food (hosted by Jillian's).
• Social Event (2): Also free pool, bowling, and ping pong. What type of a bar has a bowling alley?
• Social Event (3): There was also a dance downstairs. I have never seen so many dancing scientists and engineers in one place. More awesome.
• Jamboree (10): Finalist presentations. I liked Heidelberg's presentation about developing standards for mammalian synthetic biology. The biologists also swooned over the idea of a universal endonuclease (Freiburg) and Cambridge's pigment-producing E. coli biosensors.
• MIT vs Waterloo (5): The city and campus came back from the dead on Monday. MIT looks a lot more like MIT when it has students swarming over it.
  
• Jamboree (11): Cambridge won the grand prize. Heidelberg was the first runner-up and Valencia was the second runner up. Alberta won for "Best Foundational Advance".
• Road Trip (3): Parking cost a little over ninety dollars from Friday until Monday.
• Road Trip (4): The return trip was still a nine hour drive.
  

You Don't Know Slow

Driving below the posted speed limit is not slow. The pace of the "Fellowship of the Ring" book was not slow. A snail dragging a brick is not slow.

Then what is slow, you ask, if not these things? A computer program to simulate all possible recombinations of a couple strands of DNA, is what. Specifically, the current implementation of the Recombinatron project I've previously posted about.

We've known for a while that the program was slow. There was talk of "factorial run-time" and "exponential growth" but we didn't really pay that much attention to these things. Time's too short to waste it figuring out Big O notation when you could instead just run the program.

On a computer with 12 GB of memory.


And wait eight hours as the program stalls on step 4 of 255.

...

...

...

It turns out the program's pretty slow. Not "man, FancyApp 2.0 sure is slow" slow, but "man, this won't even be halfway done before the sun dies" slow.

Leaked Logos

Designing logos is difficult. Just ask the University of Waterloo: new logo designs that are allegedly part of a new marketing campaign have been getting lampooned with glee since they were leaked several weeks ago (on Facebook, of all places).

This brings me to the fancy circular thing at the top of this post. It is not a new UW iGEM logo; it's just me continuing to test sketching programs (the ring was drawn in Sketchbook, the lettering is from ArtRage). On the other hand, from what I've heard, the iGEM logo may soon look something like this. The reason for the logo change is due to complaints that the current use of the Waterloo lion dilutes the school's branding (more so than the new 'W' logo, apparently).

Even for a logo as simple as this test, there's a surprising number of considerations that I messed up. For one thing, it should be done with vector graphics so that the logo can actually scale, then there's all the technical errors with the perspective and shape of the gear and the DNA strands. Also, this logo is using some subtle shading that would probably get lost in most applications and having the text on the inside of the ring limits how small the logo can be made while remaining readable...

All in all, I'm really pretty glad I'm not working in graphics design.

Pandering to the Biologists

Bioinformaticians seem to be disproportionately represented in the readership of this blog, so I thought you folks might be interested in this blog post. It discusses the public relations problems faced by synthetic biology and raises Drew Endy's (presumably) ironic assertion that the field be renamed "Shiny Happy Biology".

It's probably a good thing the PR people haven't heard of our bacterial contraception plans yet.

EDIT: Actually it's a good thing they haven't heard of most of the weird iGEM projects that Andre has helpfully curated.

Canada Day!

Oh Canada!
Our home and native land,
True patriot love, in every DNA strand...

Okay, so I still have iGEM stuff on my mind, because we're continuing to code away on Recombinatron (see previous post), but it is Canada Day and that calls for celebration. The engineering jazz band is not in fact playing today, but the Water Boys (a cappella group) will be performing twice today at Columbia Lake for anyone in Waterloo (no, I don't sing with them currently -- I'm just a fan). Also, there will be fireworks and other fun. Yaayyy Canada!

RECOMBINATRON!

I spent the whole day programming for Waterloo's iGEM team. iGEM, for anyone who doesn't know, is the International Genetically Engineered Machines competition hosted by MIT, the goal of which is to figure out ways to design useful things out of biological components.

There's a subtle but important difference between iGEM's philosophy and conventional biotechnology, and it lies in the issue of design. People have been able to do things like getting bacteria to produce human insulin for a while now, by taking the human gene for insulin production and inserting it into the bacteria. What we haven't been able to do is to really understand the genes that we're dealing with.

Biological parts have been impenetrable black boxes: if something comes out of that box that we can use, that's great, but more often than not we would like to get into that box and tinker. What's more, these parts don't tend to play well with each other, and all sorts of chaos ensues when you start mixing together genes.

iGEM's approach is to create new biological parts. Parts that are not massively complex genes, but simple, reliable, reusable components that have intended purposes and known effects with other components. The goal, really, is to allow for true genetic engineering instead of genetic experimentation.

This isn't to say that all genetic parts created for iGEM are simple or reusable and it certainly doesn't mean that all that many of them are reliable, but we're working on it. The project I was coding today, for example, is intended to allow the team to predict the results of certain biological reactions, the end goal of which is to develop a repeatable method of inserting genes into chromosomal DNA.

At least, I think that's what it's for. Biology hurts my brain.