Team:Berkeley Software/Eugene Results

From 2009.igem.org

(Difference between revisions)
Line 17: Line 17:
<span id="Results"><H3>Results</H3></span>
<span id="Results"><H3>Results</H3></span>
-
Table 1 is an examination of actual experimentally created devices from a variety of sources.  The first two devices were created in the summer of 2008 in J.C Anderson’s lab at UC Berkeley for the International Genetically Engineering Machine Competition [https://2008.igem.org/Main_Page (iGEM 2008)]. These can be found in [http://partsregistry.org/ MIT’s registry of standard biological parts]. The third device is from Drew Endy’s lab at Stanford. The fourth part is from Edinburgh’s 2008 iGEM team. The fifth part is from Tom Knight’s lab at MIT. The description of these devices as well as their registry id is provided. In addition we detail the number of properties, parts, and devices used by Eugene to specify them. For running the examples a MacBook Pro was used with a 2.4 GHz processor speed and 2 GB of memory.<br><br>
+
Table 1 is an examination of actual experimentally created devices from a variety of sources.  The first two devices were created in the summer of 2008 in J.C Anderson’s lab at UC Berkeley for the International Genetically Engineering Machine Competition [https://2008.igem.org/Main_Page (iGEM 2008)]. These can be found in [http://partsregistry.org/ MIT’s registry of standard biological parts]. The third device is from Drew Endy’s lab at Stanford. The fourth part is from Edinburgh’s 2008 iGEM team. The fifth part is from Tom Knight’s lab at MIT. The description of these devices as well as their registry id is provided. In addition we detail the number of [[Team:Berkeley_Software/Eugene#Properties|properties]], [[Team:Berkeley_Software/Eugene#Parts|parts]], and [[Team:Berkeley_Software/Eugene#Devices|devices]] used by Eugene to specify them. For running the examples a MacBook Pro was used with a 2.4 GHz processor speed and 2 GB of memory.<br><br>
<p align="center">'''Table 1: Examination of Experimental Designs Specified Using Eugene'''</p>
<p align="center">'''Table 1: Examination of Experimental Designs Specified Using Eugene'''</p>

Revision as of 02:29, 19 October 2009



Content:
  •  Intro
  •  Language Definition
  •  Examples
  • Implementation
  •  Results
  •  Conclusions
    		•            
    Eugene.png

    Results

    Table 1 is an examination of actual experimentally created devices from a variety of sources. The first two devices were created in the summer of 2008 in J.C Anderson’s lab at UC Berkeley for the International Genetically Engineering Machine Competition (iGEM 2008). These can be found in [http://partsregistry.org/ MIT’s registry of standard biological parts]. The third device is from Drew Endy’s lab at Stanford. The fourth part is from Edinburgh’s 2008 iGEM team. The fifth part is from Tom Knight’s lab at MIT. The description of these devices as well as their registry id is provided. In addition we detail the number of properties, parts, and devices used by Eugene to specify them. For running the examples a MacBook Pro was used with a 2.4 GHz processor speed and 2 GB of memory.

    Table 1: Examination of Experimental Designs Specified Using Eugene

    Device Group Description Number of Lines of Code in program Percentage change Lines Ratio Compilation
    Property Values Parts Devices Total Main File Total to Main File Sequence bp:Lines Time(ms)
    [http://partsregistry.org/Part:BBa_K112809 BBa_K112809] iGEM08_UC_Berkeley (2008-11-03) T4 Lysis Device with Pbad 21 7 0 19 3 84 158:1 94
    [http://partsregistry.org/Part:BBa_K112133 BBa_K112133] iGEM08_UC_Berkeley (2008-10-30) Xis Int temperature sensitive expression cassette 31 11 1 17 3 82 128:1 94
    [http://partsregistry.org/Part:BBa_E7104 BBa_E7104] Endy Lab
    (2005-07-04)    		 T7 Consensus Promoter Sequence 10 4 0 16 3 81 68:1 94
    [http://partsregistry.org/Part:BBa_K118021 BBa_K118021] iGEM08_Edinburgh (2008-10-07) T7 Consensus Promoter Sequence 6 2 0 15 3 80 72:1 93
    [http://partsregistry.org/Part:BBa_I8510 BBa_I8510] Knight Lab
    (2008-01-09)    		 3OC6HSL->Inverter-> lacZalpha with orthogonal GFP protein generator 60 20 0 27 6 78 151:1 109
    [http://partsregistry.org/Part:BBa_F2620 BBa_F2620] Haseloff Lab, MIT
    (2004-08-09)    		 3OC6HSL -> PoPS Receiver 18 6 0 19 3 84 56:1 94
    [http://partsregistry.org/Part:BBa_J23040 BBa_J23040] iGEM2006_Berkeley (2006-08-01) AHL-dependent inverter 30 10 0 19 2 89 125:1 94
    [http://partsregistry.org/Part:BBa_J5519 BBa_J5519] iGEM2006_Toronto (2006-10-29) Arabinose -> LacI ts -| cI 434 30 10 0 19 2 89 180:1 93
    [http://partsregistry.org/Part:BBa_J5522 BBa_J5522] iGEM2006_Toronto
    (2006-10-29)    		 Arabinose -> LacI ts -| pLac -> tetR -| pTet 32 11 0 22 2 91 159:1 93
    [http://partsregistry.org/Part:BBa_K106695 BBa_K106695] iGEM08_UCSF
    (2008-10-28)    		 Sir3 under a strong constitutive promoter 8 4 0 16 2 88 291:1 94
    Total 276 85 1 189 29 -- 26436:189 952
    Averages 24.60 8.50 0.10 18.90 2.90 84.72 139:1 95.20


    The purpose of this investigation was to display the significance in the separation of Part and lower level property information, which is hidden in the header files from the Device level construction in the main file. As a result about an average of 85% less code is utilized in the main file. The real strength of the language becomes apparent with the introduced level of abstraction through the transfer of Part designs from databases to the header files. Such functionality allows the augmentation of data from other sources to the main design. The focus shifts from the low level details of the system to design validation through rule constructs and control flow implementation. The program becomes easier to manage. At the same time, the ratio of DNA base pairs to total lines of code implies the portability of very complex designs with large base pairs to other tools or systems. Sharing designs becomes much easier, especially, since the creation of the data structure is quickly achieved. The compilation times are very reasonable as the column in the table above shows. We have confidence that as designs move to encompass 10’s or 100’s of devices, the compilation time will remain very reasonable.

    back to Content

    Conclusions

    Overall, Eugene is a human writeable language that demonstrates both efficient textual representation of biological systems but also the capability of validating constructs. It presents the ability to work both on lower level property information but also on a Device level design. Eugene proves to be a portable solution to large system designs through its connection to different databases. Furthermore, based on its direct one to one relationship to standard biological Parts, Eugene can be translated to visual designs and vice versa.

    For future releases, it will be important to incorporate other control statements. The language will require a notion of systematically going through lists, which can be achieved through loops. This can be useful when different combinations of Parts or Devices need to be traversed and some operations on them performed. At the moment the highest level in the Parts Hierarchy are Devices. Ideally, we would like to extend Eugene to contain Systems and the ability to operate on such a level by providing built-in functions, which will depend on new assembly standards. At the same time the user should have the ability to create functions. This introduces the importance of scope in variables and instances, since functions should only apply to specific instances. Currently, all instances in a file can be accessed globally. Another aspect in the language is the direct access to a database. By providing a function to connect to a specified database would certainly give more expressional power to the language. Currently, data base access is performed outside of Eugene by translating XML information from the database to Eugene code.


    back to Content

    Retrieved from "http://2009.igem.org/Team:Berkeley_Software/Eugene_Results"