Calgary/evoGEM projectDesign

From 2007.igem.org

Revision as of 19:56, 26 October 2007

EvoGEM was developed using C++ and a graphics agent engine known as Vigo::3D.is a library for multi-agent simulation and visualization in 3D space that was developed at the University of Calgary by Ian Burleigh. The code for Vigo::3D is open source at available at http://vigo.sourceforge.net/docs/dox/html/main.html. By using Vigo::3D the EvoGEM project has been able to generate clear graphical representations of the systems that are evolved. This gives a nice qualitative visual view of how the system works.

The Simulations

The image shows a still screen shot from one of the movies generated by EvoGEM. The large fairly transparent purple spheres represent RNA Polymerases. These polymerases are preprogrammed in with characteristics that define their ability to bind to the promoter, which is the darker green bar at the end of the main circut. The lighter green portion corresponds to a ribosome binding site, the purpleish pink component represents the protein coding region and lastly the red part at the end of the circut is a terminator. The definitions of the other spheres floating around represent various proteins and other factors whose function will be dependent on the type of simulation being run.

The parameters of the simulation are determined before running the simulation by setting the values in a configuration file. These files determine the nature of the simulation. The configuration files allow the user to define, among other tihngs:

• The number of generations
• The target products the system should evolve
• The mutation rates of each generation

EvoGEM and The Registry

As of yet EvoGEM lacks the ability to connect with iGEM registry and dynamically search for parts. As such our system works off of a "mini registry" file that contains approximately 200 parts. Parts from the registry are described in a way that is easily understandable by humans but very hard for a computer system to work with. Therefore the parts in our mini registry have been manually composed by reading through the part descriptions, determining which parts of the description have value to the simulation and then defining them in fields that our simulation can interpret. The result was the development of several descriptive fields which our system will recognize values for and then make the appropriate selections. Some of our fields are:

• Type - what type the part is. ie Promoter, RBS ect
• Part - The ID of the part
• Input - What the part inputs to our system
• Output - What the part outputs from our system
• Inducer - What is required to induce expression of the part
• Represser - What will repress expression of the part