Team:BostonU/Software
From 2014.igem.org
(Difference between revisions)
Line 22: | Line 22: | ||
<tr> <td scope="col"> | <tr> <td scope="col"> | ||
- | 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 arrangements of parts. In miniEugene, a user only specifies parts and rules and gets all possible devices back out. | + | 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 arrangements of parts. In miniEugene (screenshot below), a user only specifies parts and rules and gets all possible devices back out. |
<br><br> | <br><br> | ||
<br><center><img src="https://static.igem.org/mediawiki/2014/8/82/BU14MiniEugene_Screenshot.PNG" width="75%"></center> | <br><center><img src="https://static.igem.org/mediawiki/2014/8/82/BU14MiniEugene_Screenshot.PNG" width="75%"></center> | ||
+ | |||
+ | <br><br> | ||
In this project, we used miniEugene to deduce all possible arrangements for a priority encoder with our part library. We used Eugene to refine this large list of possibilities and ultimately randomly chose one of the solutions to implement. | In this project, we used miniEugene to deduce all possible arrangements for a priority encoder with our part library. We used Eugene to refine this large list of possibilities and ultimately randomly chose one of the solutions to implement. | ||
Line 41: | Line 43: | ||
<td scope="col"> | <td scope="col"> | ||
- | Raven is a software tool for determining optimized plans for cloning constructs or sets of constructs. It supports a number of contemporary cloning methods, including our MoClo method. The Raven algorithms maximize the sharing of intermediate parts and vectors and pre-existing library parts for each 'assembly'. It produces oligos and step-by-step cloning instructions for human and computer users to build all target devices. | + | Raven (screenshot below) is a software tool for determining optimized plans for cloning constructs or sets of constructs. It supports a number of contemporary cloning methods, including our MoClo method. The Raven algorithms maximize the sharing of intermediate parts and vectors and pre-existing library parts for each 'assembly'. It produces oligos and step-by-step cloning instructions for human and computer users to build all target devices. |
<br><br> | <br><br> | ||
<br><center><img src="https://static.igem.org/mediawiki/2014/3/3a/BU14Raven_screenshot.PNG" width="75%"></center> | <br><center><img src="https://static.igem.org/mediawiki/2014/3/3a/BU14Raven_screenshot.PNG" width="75%"></center> |
Revision as of 02:11, 17 October 2014
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 arrangements of parts. In miniEugene (screenshot below), a user only specifies parts and rules and gets all possible devices back out.
In this project, we used miniEugene to deduce all possible arrangements for a priority encoder with our part library. We used Eugene to refine this large list of possibilities and ultimately randomly chose one of the solutions to implement. |
Raven for Building Devices
Raven (screenshot below) is a software tool for determining optimized plans for cloning constructs or sets of constructs. It supports a number of contemporary cloning methods, including our MoClo method. The Raven algorithms maximize the sharing of intermediate parts and vectors and pre-existing library parts for each 'assembly'. It produces oligos and step-by-step cloning 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. 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
We used the SBOL community data model standard to represent the priority encoder so that we can share the design with other synthetic biologists.
|