Team:BU Wellesley Software/Notebook/ChenkaiNotebook

From 2011.igem.org

Revision as of 03:29, 23 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 grown, 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

Week of 7/11-Parallelism and Optimization. Optimize movement to pipette from many wells at the same time instead of using only one Diti at a time

Today: So today was rather productive. Me and Viktor communicated over Skype in the morning to get some final bugs fixed and we met up at the wetlab at 3pm to test our protocols on the robot. We first tested running 3 restriction digests in a row, verifying the correctness of our pipetting with the printout of a event logger that told us what is 'suppose' to happen. Our testing of 3 restriction digests worked fine, but we ran into a 'Out of Resources Exception' when we tried to test with 9 restriction digests. We then spent 40 mins trying to debug this error and finally managed to fix the problem. We next used the same method to test 1 ligation and it worked fine, we then tested 5 ligations in a row and its pipetting pattern also matched what we expected. What we need to do now is to connect the restriction digests and ligations so the ligations will use samples created from the restriction digest as its input samples.

  • Tuesday 6/21

Today was the date of the awaited Joint iGem meeting. I gave everyone an update on ResourceManager and progress on the robot side. The meeting lasted longer than expected but it was productive. I was curious on what the wetlab side have been doing and now I am all up to date with everyone's progress. After the meeting, Viktor, Swapnil and I went over to the Wetlab and retested the 9 restriction digests and 5 ligations. I was there to help verify the 9 restriction digests but had to go at 6.

  • Wednesday 6/22

We had the Comp Meeting today with Doug and he added a number of things onto my todo list:

6-22-11 Comp Meeting ToDo 1. Human Readable RD-> Ligate Connection 2. Consumable Expense, Calculate Plates, Tips, Type 2a. Cost $ (bonus) 3. Consumable projection report 4. Plan to learn from Viktor by 7/9 5. “Plate” allocation 6. Puppeteer DB -> schema

I now have my work cut out for me for the next few weeks. Me, Swapnil, and Viktor had a juicy discussion about how to deal with the plate allocation issue. How does Puppeteer/ResourceManager figure out what plates are least needed and make room on the deck when the deck clutter's up with plates. We agreed to execute a 3 pass method to do this, the first pass calculates resource requirements and initializes the deck, the second pass figures out what plates are accessed at what time, and during the third pass we actually passes instructions to the robot. By this point, the resource manager knows how to make room on the deck and put what plates in the hotel depending on the access time for each plate.

  • Thursday 6/23