From 2009.igem.org

Nina 2 June 2009

Today is the second day of iGEM. Yesterday I spent time looking at java tutorials.

New Tasks Given are to look at tutorials for wiki that will be working or not -- media wiki embedded html for complicated stuff keep clean, so no need to clean up later think of a plug-in 1 wiki entry per week

Nina 3 June 2009

Nina Revko. IGEM 2009.

My 1st official entry

I am a member of computational team, majoring in bioengineering in fall 2009.

On Monday my team met, and everyone got acquainted with each other. We are still missing one member Lesie, who will join the team on Monday. After meeting with members of computational team, everyone went for a lab safety training and lunch social, where we met other members and leaders including the participants of the wet lab. Instructors were surprised with the size of this year's iGEM team.

Even though, we started working only on Monday, today is Wednesday, and everyone is overwhelmed with tasks and information. I think that we will adjust very soon and will produce effective results.

We got acquainted with Clotho, NetBeans, some Clotho code and CVS already.

This week short-term goals:

search for bugs in Clotho
edit Notebook
modify .html help files

MainToolBar
MySQLlogin

Longer short-term goals:

proof-read and become familiar with the rough draft of paper for assembly of biological parts(implementation of dynamic programming - hash tables in Java - and determining the minimum cost for assembly)
together with Bing, meet with Chris Anderson and Jenn and learn how the robot works in the wet lab + their protocols (.csv file)

Long term goal for the 1st part of iGEM:

Robot/Automation project (brief structure):

select parts (basic and compound)
- do it through Part Manager - 1 click
- put in Algorithm Manager
run Assembly Algorithm w/Algorithm Manager Plug-in => record wells and physical locations of the each part
create 2 protocols (.csv)
1. human
2. robot

both protocols should take into account actions that user should perform (grab samples from freezer with appropriate bar code - talk to wet lab members); the way dilution will be performed; the way plates will be managed before the complete assembly takes place (Plate Manager)

Nina 5 June 2009

After meeting with J.Christopher Anderson... The questions raised:

how to delete theoretical parts from the database (with no associated physical part?
requirements that will be tried to be implemented with the following assumptions:
- start with a single plate where the basic parts are located - are all in 1 plate put there by user
- cell stocks are not taken into account initially
- bring parts in/out - allow for flexibility and playing around with parts
- export assembly tree into a .csv file for robot with taking into account of "left-y", "right-y" and different antibiotics compatibility (AC, CA, AK, KA, CK, KC) - "lefty"/"righty" are currently not specified in db
- after the robot is done and parts were made, display what parts were successful -- allow for user's input (in form of a tree?!)

Nina 10 June 2009

Yesterday I made my first sample plugin. It was not difficult, but took some time to debug and find out what did not work. The plugIn file name should be "plugin.xml" and it is very important to preserve that format. Yesterday I had another meeting with wet lab representatives discussing the robot protocol. Also I had a chance to take a look at the AssemblyAutomationPlugin on which I will be working in the nearest future. Today Jenn from the wet lab sent the protocol they are using for the robot and I am going through analyzing it right now. Some notes:

min volume for robot - 3ul
max volume for a single 96well plate - 200 ul
max volume for pippetting/mixing for robot???
digest cocktail and lysis mix cannot be done by hand (from Bing)

stock plate (96 well with mini preps)
bigStock plate with H2O, buffer, lysis mix, digest cocktail
dilution plate
reaction plate

Looking at protocol, there should be several blocks done:

running the SDS assembly algorithm, determine the amount of every basic part needed for the building of the final goal part(? what to do about the extra volume of the required reagents? multiply the volume by which factor assuming that some stages need to be re-tried?)
?should we take into account the amount of the stock and prep sep one for each STAGE?
done by user at the present time: making basic parts and miniprep (?put in DB); put in 96 well plate at this time
dilution block (Input--the wells and plate locations of the miniprep and basic parts - if they are in stock plate as specified by the protocol after SDS algo, locations are known); check if the user messed up the plate; the plate with NEB2 Buffer (bigStock)
---function to pippet the same reagent in many wells
---function to transfer one miniprep from STAGE1 plate into STAGE# plate
Digest block: (Input--the destination wells from the dilution block & stock of digest cocktail; output - destination wells)
Ligation block...

Nina 15 June 2009

The general meeting took place during regular Monday hours. Presentation of three projects left everyone with full-filling thoughts that something great is happening in our group and that people are totally not familiar what everyone is doing. This meeting and the upcoming Thursday meeting will keep everyone up-to-date and provide certain info-sessions on ongoing projects.

Nina 17 June 2009

I had meeting with my advisor. It took me about 40 minutes to put my thought and my code in order to present it and to talk about it. After the meeting I decided to work on the upcoming presentation that I had to make on Thursday. I spent some time working on presentation. The thoughts start coming in order and new fresh ideas about how the code is supposed to work, developed. I came to the conclusion that my Friday deadline will be missed but that I could finish by Monday...

Nina 20 June 2009

Last week the directions of what to do were clearly stated, the protocol for assembly procedure was obtained and several meetings with Doug Desmore and Chris Anderson was held. The part of the last week and this week I have been working on the assembly plugin.

Ideally my piece fits in the following scheme and should communicate with database (will be implemented later) and algorithm manager:

Nina Revko - ideally...

The work flow of the currently implemented changes will support the following operations:

take in SDS tree->process it in 3 arrays with data and one array with stages
based on a stage given by user, the program will pull out all resultant nodes together with lefty/righty parts
taking into account the future use of the part (as lefty or/and righty or as final product), the resultant nodes are sorted in the order of lefty/none/righty and will be put in wells of the reaction plate in that way
the initial well assignment to stock, dilution, reaction plate for a single stage is performed by the first method based on resultant usage
BigStock plate is currently hard-coded and holds dilution buffer (A5/A6) , digestion mix (B5/B6) and ligation mix (C5/C6)
one to many non-empty assigned/(modify this to do assignment for wells)
redundancy check for the stock and dilution plates performed, wells reassigned (3 functions)
- destinations and assignments scheduled for destinations are modified and reassigned
convert everything to 3 files for dilution, reaction and ligation processes
create user file - instructions for user

More graphical presentation of what the program should do is below:

Nina Revko - part1

Nina Revko - part2

The basic things to keep in mind:

min volume to pipette from single channel is 3ul (for accurate pipetting need 8ul in a well
max -"- 20ul
robot does mixing and changing of tips automatically
preferably stuff from Big Stock Plate goes in wells first (email Chris to ask whether it's important)
allow to integrate between pipette in rows or columns (specificity of the plate in our case, defined by user)

Upcoming work:

convert destinations to destination parameter class
finish cleanUpRedundancy function
modify it to keep track of well assignments
debugging, debugging, debugging
go in wet lab to test it
create GUI with possibilities of user-defined properties like to which file to save; to pick a stage, etc.

Nina 28 June 2009

For the past week I was working on fixing bugs. Over the week my program was able to produce correct output files with no errors =) Hooray!

On Friday, I went to wet lab and found out that they want more from my program that the piece that I made was not enough for them to do the testing. I was a little bit disappointed and worked a lot during week-end fixing and reorganizing pieces. I added:

a sorter for the resultant parts and populating the reaction plate besides lefty/righty, also according to 6 types of antibiotics
created an option for user to read in the stock plates from the text file (includes the possibility of having multiple stock plates)

Still to work and to do before showing up in front of the wet team:

do automatic plate assignment (currently hardcoded)--it is required for the multiple plates
do the file output for plating
do the user choice for antibiotic and their reassignment--by user!!!--it should be somewhere in tree

Nina 2 July 2009

It is a short week with long coming week-end. But this week was somewhat productive.

Done:

the user gets one of the 6 choices of antibiotic assignments that s/he can use

the user can input his/her own file (instead of database which is being worked on right now) for where the parts are coming from for dilution
- supports only specific format .txt--which can be constructed by coping tables from the .xls file:

PlateName/(tab)/WellPosition/(tab)/PartName/(tab)/Antibiotic1/(tab)/Antibiotic2/(tab)/leftyOrRighty (or putting the preceding information into the excel columns and saving the file as a tab-delimited text file)

Eg.:

the resultant(reaction) plate is being sorted by the program according to Righty/None/Lefty and according to 6 choices of antibiotics within the plate itself
the plating file for the preparing of culture with antibiotics is produced (the transfer of resultants from the reaction plate to antibiotics plates is made by user using multipippetting channel)
allows multiple stock plates
cleans up robot decks from the used plate between steps
outputs modified user file with instructions

Assumptions:

no more than 48 wells/resultants can be implemented for one stage (=>no more than 1 dilution plate and one reaction plate are used)
the final parts for assembly interlink somewhere in between in some of the basic or composite parts (antibiotic distribution assumes sharing)
the user uses multipippetting channel to pippette buffer into dilution plate
the user uses multipippetting channel to transfer resultants from reaction plate to platting with antibiotics
the user has/creates text files or agrees to comply with created stock plates for each stage

Today

Bing and I went to wet lab, talked to Jenn, and we decided to do testing on Tuesday. Jenn should prepare parts that we will use for a simple assembly testing.

TODO before Tuesday:

clean-up code
do some testing (look for unfixed bugs)
consider moving antibiotic selection before the stage selection
re-do the text window option for the showing of the assigned plates

--NinaRevko 23:16, 2 July 2009 (UTC)

Nina 3 July 2009

Berkeley Comp IGEM Team 2009

Eugene Team

Adam and Lisa are babby-sitting Eugene

Kepler Team

Thien is working hard with Kepler

Visualisation Team

Richard and Joanna - drag-and-drop masters

Automation Team

Nina is conveying a talk to robot

Clotho Data Model

...and the person who also participates in Kepler and Automation teams!

Bing - core master

The person without whom there will be no teams...

Doug - the IGEM God, is bridging gaps between EECS and Bioengineering in his spare time

Nina 12 July 2009

This week was somewhat short. On Monday wet and comp teams had the first general social event. On Tuesday I went to wet lab, and the wet lab requested output files in a certain way and some of the parameters to be kept constant. I finished wet lab request by Wednesday, sent email to Jenn about the possible run and received a reply that we can test it on the real parts, but that the run has to be postponed for 2-3 days due to basic parts being in progress. The rest of the week I spent working on fixing of the current interface of the plugging, modifying some functions to accept users input and to allow for the parameters check. I also cleaned up code and bettered my comments on the functions.

Here's the description of my main program in the plugin: What happens here?

The parts from results, leftyParts, rightyParts arrays get picked according to stage index.
The reaction plate is organized first for resultant parts as (Righty/None/Lefty) and each of those
three instances are also sorted by antibiotics; at the same time the stock plate and dilution 
plate are organized. Then the cleanUpRedundancy function removes repeating wells if they can be
combined together with other wells holding the same substance. That process is performed for
stock plate, bigStock/enzyme plate and dilution plate (reaction plate is organized from the beginning to exclude  
redundancies).
The user gets a chance to view how computer organized the stock plate, and if the user has a his/her stock parts
in a separate/different plate(s), s/he can load a text file and the program will reorganize stock material - 
mini-preps - according to user's choice assuming the format of the text file is the following:
PlateName(where the compound is)/[tab]/WellName/[tab]/PartName/[tab]/Antibiotic1(A/K/C)/[tab]/
                                                                                    /Antibiotic2(A/K/C)/[tab]/L or R
These files can be constructed in excel and saved as text documents, then the tab separation between columns is kept.
With manipulation of assignment to the plates and destinations from the plates, files become created for User (with 
no extension), and robot: for dilution and reaction.
Then the platting with antibiotics of the resultants is assigned to the platting plates and also .csv files are 
created.

Nina 13 July 2009

Today is Monday. The majority of clean up has been done. Now I am waiting for the wet lab to give me basic parts to assemble so I can check them and to decide on the date of the run. Besides that I am looking forward to learn more about my new project. Doug said that I might be able to implement another robot with similar protocol, writing a program for it.

Nina 21 July 2009

Last Tuesday, Doug announced Thien and me as a group, so now I am learning Kepler and getting started with Eclipse - the programs that Thien is working with.

Doug, Thien and I went to JBEI on Thursday. We talked to Nathan Hillson and Masood Hadi. They showed us their robots, Masood suggested to look into Hamilton systems (Swiss Co.), and that normalizing plates can be useful and doable from the perspective of what I am doing right now. Next week on Wednesday, we are planning to meet with Nathan again, and to go over the work-flow that he has been working on in person.

By Thursday of this week, I have to have a picture of my complete work-flow ready in Kepler.

Nina 24 July 2009

The Kepler picture is ready. Of course, it is just a raft draft of what we are making, but in a long term, it might be implemented.

Kepler-Clotho Automation.

For the past couple days, we installed Kepler on my computer, which required installation of Eclipse, svn, manual ant, and something else, and I did today the "Hello World" actor. The problem arose when running Kepler with new actor. For some reason build was changed and it tried to run the program with Kepler version 1.0 instead of the current version (manual changing in module-info helped).

Now I am modifying my automation code to be more suitable for work with "actors" and "directors". Hopefully, some break through could be done next week.

Nina 31 July 2009

This week was very intense in terms of ideas.

Unfortunately I have to roll back my computer to its factory settings and after that re-install all the programs. But besides that Thien, Doug and I went to JBEI and received some new information on work-flows that are currently being investigated and adopted. Now we are reading papers and preparing our questions to the JBEI contact (Nathan and Will). The general idea is still to finish an automation work-flow in Kepler by Monday.

Besides that the team is migrating data to ClothoCAD and SourceForge, and setting up svn access to source-file sharing.

From the sad news, Leisa is leaving tomorrow, so we are loosing one of our team members. Next time we will see her at Jamboree.

Nina 3 August 2009

The Kepler automation workflow is almost done! The main difference from Clotho is that it does not allow user's choice of input file (this will be modified later by connection to the database), and RMI tool is not completely ready yet.

Nina 7 August 2009

This week Thien and I went back to JBEI and met with Tim. He offered his prospective on how the algorithm should function and helped to organize it in a some understandable piece.

We have been looking at Golden Gate method. There are bins with the same overhangs of 4 base-pairs. Bins contain sequences. The user can choose whether he wants the reading frame to be conserved (linker of 3/4/6 base-pairs), select whether linkers are present at all, select AA for the linker if present (mostly used are Ala, Gly, Ser), and tell the program what kind of sequences are in the bin (promoter, protein, RBS, etc.), select what cell the final constructs will be put into (human/E.Coli - this is necessary for elimination of rare codons during selection process).

So far, that is what the program should do after the user's choice is made:

create a table of acceptable codons eliminating rare codons
search for internal restriction sites, do silent mutation (2 additional primers, probably 20 bps, centered on the base that will be mutated)
design 4 bps overhangs
- should be expanded
add external recognition sequences for endonucleases to the overhangs
design final set of primers for each sequence in a bin

Program should be independent of the starting vector and hopefully final vector.

Nina 14 August 2009

This week I have been working on the JBEI project. Thien and I also received task to design a display case for CHESS, which I will be working on this week-end.

Thien, Doug and I met with Will Holtz this Wednesday, and Thien's project became well-defined.

After emailing back and forth with Tim and Nathan from JBEI, the project was specified even further. The final goal of the project is the ability to make all possible permutations between bins. And the general definition of the overhang is a Wobble base pair from i-bin + a linker or the first codon from (i+1)-bin. The interesting case is protein fusion, when the linker is absent but the Wobble base pair in i-bin has to be triggered to stay the same, and the first AA/codon in (i+1)-bin has to be the same in order to form exactly the same overhang between 2 bins. At the present time I have implemented functions that allow for selection of the Wobble base pair as bp that occurs the most in the bin, putting all other sequences into "undoable" section of the bin, and selecting AA for the second bin that occurs the most in the same manner.

Now I need to create linker-selection.

During the process of selection the following steps need to be taken:

create an array that will keep track of implemented overhangs (and may be their reverse complements)
once linker is selected, check overhang for uniqueness
if unique, check linker for being palindromic
if it is, look for the available linkers in the bin
if nothing works, then try to go back and either:
- to change the Wobble base pair in one of the bins with the same W-bp with minimal losses and shift that linker to the present place
- or to shift the linker (if it's 3bps) to the other overhang with different Wobble bp (do swap)

Most likely non-protein fusion cases will work with 4bps-linker which is the same as the overhang, and will not leave any choice if the available linkers were exhausted from the bin. 6bps-linkers can offer advantage of higher variation and availability to choose.

More questions are planned to be discussed on Tuesday meeting at JBEI.

Nina 23 August 2009

This Friday was officially the last day of iGEM, but we will continue to work on the projects further.

This week Thien, Doug and I went to JBEI and received better description of the project on which I'm currently working. The task was simplified, but the general theme was left unchanged. Besides that, my draft for the CHESS display was reviewed by Christopher Brooks and Doug took over the slides, which helped a lot and left more time for the project with JBEI.

My classes start on Wednesday, but I will still continue working on the iGEM project.

Team:Berkeley Software/NinaNotebook