Team:Berkeley Software/Eugene Results

        

- 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 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 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 Up

 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 Up