Team:BostonU/Software

From 2014.igem.org

(Difference between revisions)
Line 45: Line 45:
In this project, we took the output priority encoder design from Eugene and determined a cloning plan with Raven (see below). We chose to assemble the parts using MoClo, since we started with an existing library of parts in a MoClo format.
In this project, we took the output priority encoder design from Eugene and determined a cloning plan with Raven (see below). We chose to assemble the parts using MoClo, since we started with an existing library of parts in a MoClo format.
-
<br><center><img src="https://static.igem.org/mediawiki/parts/a/a0/Priority_encoder_assm.png" width="100%"></center><br>
+
<br><b><center><img src="https://static.igem.org/mediawiki/parts/a/a0/Priority_encoder_assm.png" width="100%"></center><br><b>
<h3>TASBE Tools for Testing Devices</h3></td></tr>
<h3>TASBE Tools for Testing Devices</h3></td></tr>

Revision as of 01:02, 18 October 2014



Bio-Design Automation Software Tools Used in Project Chimera
Chimera integrates three main software tools into the design-build-test cycle. The design and assembly of devices are facilitated by Eugene and Raven, both of which use a software tool called Pigeon for depicting genetic devices in the SBOL Visual Format. We employ the TASBE Flow Cytometry Tool for presenting flow cytometry data in absolute units of fluorescence. By using this software toolkit, not only is our process of designing, building, and testing devices more streamlined, but usage of Pigeon and the TASBE Tools make sharing of data between users and labs more efficient.

Eugene for Designing Devices

Eugene is a domain-specific language that can be used to generate designs for genetic devices from genetic parts. In Eugene, a user may specify parts, part properties, and devices composed from the available part types. The user can use product and permute functions to explore the combinatorial design space from the input library of parts and apply design rules (i.e. constraints) to narrow down the size of the design space. Another tool in the Eugene ecosystem, miniEugene, can also be used explore the design space of device arrangements. In miniEugene (screenshot below), a user only specifies parts and rules and gets all possible device arrangements that satisfy the input constraints as output.




In this project, we used miniEugene to produce all possible arrangements for a priority encoder with our part library. We used Eugene to refine this large list of possibilities and randomly chose one of the designs to build in the wet lab.

Raven for Building Devices

Raven (screenshot below) is a software tool for determining optimized assembly plans for cloning genetic devices or sets of devices. It supports a number of contemporary cloning methods, including BioBricks, Gibson, and MoClo. The Raven algorithms maximize the sharing of intermediate parts and vectors and pre-existing library parts for each assembly project. It produces oligos and step-by-step instructions for human and computer users to build all target devices.


In this project, we took the output priority encoder design from Eugene and determined a cloning plan with Raven (see below). We chose to assemble the parts using MoClo, since we started with an existing library of parts in a MoClo format.

TASBE Tools for Testing Devices

Here, we describe how we used BBN Technologies TASBE tools for analyzing our flow cytometer data obtained during the Test part of our Chimera Workflow. To view our experimental results, please check out our Data Collected page.

BBN Technologies TASBE tools, we were able to quickly and easily analyze the flow cytometry data obtained for our various devices. We collected data using a BD LSRFortessa outfitted with a high throughput sampler, allowing for the fast capture of 50,000 cells per sample in a 96-well format. Since we focused on using green fluorescent protein (GFP) and red fluorescent protein (RFP) for our reporter proteins, we utilized the 488nm blue laser with a 530/30 filter and a 561nm yellow green laser with a 610/20 filter, respectively. The GFP protein is excited by the 488nm laser and emits light that will be collected by the 530/30 bandpass filter, while the RFP is excited by the 561nm laser and emits light that will be collected by the 610/20 bandpass filter.

Below, you can see more details of our experimental design and the controls we used, which are required by the TASBE tools in order to convert the arbitrary fluorescence units obtained from the flow cytometer into absolute units in the form of molecules of equivalent fluorescein (MEFL). This allows the user to show their data in absolute units that then allow scientists to compare experiments across labs and machines.

As a part of these controls, we used Spherotech's 8-peak particles (RCP-30-5A) in order to obtain standard MEFL units for the FITC channel. They are also used to measure the long term performance of the flow cytometer and are included in every experiment run through the flow cytometer.

The Cytometer Setup and Tracking beads offered by BD Biosciences were also utilized to set the laser delay and optimize the cytometer settings 15-30 minutes prior to running any samples through the Fortessa.






In order to obtain MEFL measurements for the RFP protein, we had to utilize a dual positive control that had a FITC channel fluorescent protein and a Texas Red channel fluorescent protein. We used GFP for our FITC control and RFP for our Texas Red control. We used the MoClo versions of the J23014 promoter in both devices, E1010 for RFP and E0040 for GFP, along with the BCD2 5'UTR element and B0015 terminator. For the two color controls, we built them with the same parts, with RFP in the first transcriptional unit and GFP in the second for one control and vice versa for the other control (shown above in Controls figure).

SBOL for Sharing Devices

Upon completion of designing, building, and testing of our genetic devices, we wanted to share this information with the community. There are a variety of database options and data sharing options, so we decided to use the community standard conventions for representing our data when possible. In this case, we opted for the SBOL community data model standard to represent the priority encoder. Although the published data model is not fully expressive of all of the information we use in our workflows, it can minimally represent the sequence features of our target and intermediate constructs.









Our Sponsors

Retrieved from "http://2014.igem.org/Team:BostonU/Software"