Team:BU Wellesley Software/Notebook/ChenkaiNotebook

From 2011.igem.org

Revision as of 02:12, 21 June 2011 by ChenkaiLiu (Talk | contribs)

Chenkai iGem Notebook

Work Stack

CHECK-why does resourcemanager give the printout out of order? investigate

CHECK-tell user when new plate gets allocated

CHECK-record reaction history, also protocol history

CHECK-debugging purposes, log everything that happens

CHECK-add incubator

CHECK-add string name for wells and incubator slots, plates

CHECK-unique identifier for each well/sample

CHECK-fix duplicate restriction digests

CHECK-there are 50ul, 100ul, 200ul tip sizes, must specify

CHECK-if two wells have partial amounts, combine them

CHECK-swap column and row

CHECK-Talk to Jeno about Puppetshow GUI

-different buffer for each protocol

-be generic with plate dimensions, specifying locations (grid/site), this is only with the Tecan robots

-move transversing the tree out of assemblymanager, we want to a separate **program to annotated the tree and produce the protocol graph

-fix naming, 3 parts (UUIDS,User defined names,auto-generated linearized tree name)

-save resourcemanager state


Work Diary

  • Wednesday 6/8

Just flew back from China, got to PHO209 at 4pm and caught up with other team members on what they are up to. Had a discussion with Viktor about the road ahead, what problems are on our to do list.

  • Thursday, 6/9
    New Puppeteer output with UUIDS replacing sample names

Found a fix to the sample name duplication issue, instead of using sample names to identify sample, we are now adding a new UUID field to each liquid, this 8 digit randomly generated code will make sure no two samples of the same content will be confused with each other. Two UUIDS are generated for each sample, one for Pre-Restriction_Digested version and another for Post-Restriction_Digested version.

  • Friday 6/10

Implemented tips of different sizes, 50ul, 100ul, 200ul

Removed duplicate entries from Puppeteer output

Implemented incubator functionality

  • Monday 6/13
    Prints out the history of a sample

Planned and implemented history recording, reaction history and incubation history

Got the robot moving and tested in the wetlab

  • Tuesday 6/14

Swapped rows with columns to optimize robot pippetting

Added feature to ResourceManager to combine liquids in multiple wells to minimize waste

  • Wednesday 6/15
    Debugger printout log of what "should" happen during Evo150 execution

For debugging purposes, log everything that happens. More specifically, the content of what well should be pipetted to what well

Implemented Protocol History recording for samples

Talked to Janoo about what how the PuppetShow GUI show look like and what functionality it should have

  • Thursday 6/16

Resource Manager now notifies the user when a new plate gets allocated

Helped Viktor debug Resource Manager, it was giving him a "java.lang.reflect.InvocationTargetException" exception. It turns out he was encountering a "WellOverFlowException" which simply shows up as a InvocationTargetException on the python side. I changed it so now it prints the error message instead of giving an unambiguous exception

Formulated a new way to name samples in Resource Manager, details are sketched out but awaiting for agreement from Viktor and Aaron

  • Friday 6/17

Aaron came over today to discuss the issues of sample naming and sample history. He raised a good question during our discussion about how to implement sample history, he asked us what are we going to be doing with the history, and is it worth the time to look in sample history implementation or is it not critical at the moment. We agreed that it should be something to do in the longer term.

Took the protocol graph annotation out of AlgorithmManager and into a separate file called ProtocolGraphAnnotator.java. I emailed this file as well as SDSTree.java which I have modified to Janoo and he got the Puppeteer output generation working on his GUI.

  • Monday 6/20

1. What I have done in the past 2 weeks is mostly making gradual improvements on Resource Manager. I have been keeping in close touch with Viktor and helping his debug each time he encounters a bug on the Resource Manager's side. I fixed the bugs that we found during the Tasby's meeting as well as features that needs to be implemented. For example, I implemented the incubator as well as differing DiTi sizes.

  We are currently finishing debugging RM and Puppeteer and getting ready to test the whole flow on the robot. I am also working to revamp all the format of all the JSON Objects that are being passed back and forth between Puppeteer and ResourceManager to a more consistent and predictable format. Me and Viktor agreed that as RM growd, the differing return formats for each individual method is becoming harder and harder to manage, so this new format will make it easier for users to understand what those returns are.

2. My work fits into the overall iGem project as the bridge between Clotho design and physical assembly. The automation in assembly completes the entire workflow from a high level description to physical assembly. This is something that not every lab can do, but we have both the software platform and the Evoware robot to complete a design from start to finish with the push of a few buttons.

3. There are a number of features and hurdles that we bypassed using a pretty hackous solution just to get the flow working, those short term approaches must be finalized with more permanent implementations.

Week of 6/20 -Revamp JSON formats -Sample Naming, a. UUID b. Auto-Generated Linearized SDSTree c. User-defined names

Week of 6/27 -Sample History Implementation and Search

Week of 7/4 -Learn Puppeteer/Python for July demo -Get the entire workflow debugged and tested