"
Team:Berkeley Software/Eugene Results
From 2009.igem.org
Adam z liu (Talk | contribs) |
Adam z liu (Talk | contribs) |
||
| Line 2: | Line 2: | ||
<table align=center> | <table align=center> | ||
<tr> | <tr> | ||
| - | <td><span id="contentMenu">''' | + | <td><span id="contentMenu">'''Contents:'''</span> |
<li>[[Team:Berkeley_Software/Eugene#Introduction|Introduction]] | <li>[[Team:Berkeley_Software/Eugene#Introduction|Introduction]] | ||
<li>[[Team:Berkeley_Software/Eugene#Language_Definition|Language Definition]] | <li>[[Team:Berkeley_Software/Eugene#Language_Definition|Language Definition]] | ||
| Line 203: | Line 203: | ||
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. | 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. | ||
<br> | <br> | ||
| - | <p style="text-align: right;">[[#contentMenu|back to | + | <p style="text-align: right;">[[#contentMenu|back to Contents]]</p> |
----- | ----- | ||
| Line 211: | Line 211: | ||
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. | 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. | ||
| - | <br><p style="text-align: right;">[[#contentMenu|back to | + | <br><p style="text-align: right;">[[#contentMenu|back to Contents]]</p> |
Revision as of 21:05, 19 October 2009
| Contents:
|
 |
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.
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.
