Team:USTC-Software/tech&algo
From 2011.igem.org
(37 intermediate revisions not shown) | |||
Line 27: | Line 27: | ||
a:active, a:hover { color: #0683ab; text-decoration: underline; } | a:active, a:hover { color: #0683ab; text-decoration: underline; } | ||
- | img { margin: auto; padding: 0px; border: none; display:block;} | + | img { margin: auto; padding: 0px; border: none; display:block; } |
#header_wrapper { | #header_wrapper { | ||
Line 207: | Line 207: | ||
font-family: Verdana, Arial; | font-family: Verdana, Arial; | ||
font-size: 14px; | font-size: 14px; | ||
+ | } | ||
+ | |||
+ | #intro p { | ||
+ | font-family: Verdana, Arial; | ||
+ | font-size: 12px; | ||
} | } | ||
Line 284: | Line 289: | ||
/* end of footer*/ | /* end of footer*/ | ||
- | + | .ul_p{ | |
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
font-family: Verdana, Arial; | font-family: Verdana, Arial; | ||
- | font-size: | + | font-size: 14px; |
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
} | } | ||
Line 333: | Line 314: | ||
<li><a class="on" href="https://2011.igem.org/Team:USTC-Software/project">Project</a> | <li><a class="on" href="https://2011.igem.org/Team:USTC-Software/project">Project</a> | ||
<ul> | <ul> | ||
- | <li><a href="https://2011.igem.org/Team:USTC-Software/documents">Documents</a></li> | + | <li><a href="https://2011.igem.org/Team:USTC-Software/documents">Documents Parser</a></li> |
<li><a href="https://2011.igem.org/Team:USTC-Software/models">Models</a></li> | <li><a href="https://2011.igem.org/Team:USTC-Software/models">Models</a></li> | ||
- | + | <li><a href="#">Views</a> | |
+ | <ul> | ||
+ | <li><a href="https://2011.igem.org/Team:USTC-Software/aview">Assembly View</a></li> | ||
+ | <li><a href="https://2011.igem.org/Team:USTC-Software/bview">Behavior View</a></li> | ||
+ | <li><a href="https://2011.igem.org/Team:USTC-Software/nview">Network View</a></li> | ||
+ | </ul> | ||
<li><a href="https://2011.igem.org/Team:USTC-Software/tech&algo">Technology & Algorithm</a></li> | <li><a href="https://2011.igem.org/Team:USTC-Software/tech&algo">Technology & Algorithm</a></li> | ||
- | <li><a href="https://2011.igem.org/Team:USTC-Software/tutorial">Tutorial</a></li> | + | <li><a href="https://2011.igem.org/Team:USTC-Software/tutorial">Tutorial & Demo</a></li> |
</ul> | </ul> | ||
</li> | </li> | ||
- | <li><a href="https://2011.igem.org/Team:USTC-Software/notebook">Notebook</a></li> | + | <li><a href="https://2011.igem.org/Team:USTC-Software/notebook">Notebook</a></li> |
<li><a href="https://2011.igem.org/Team:USTC-Software/team">Team</a> | <li><a href="https://2011.igem.org/Team:USTC-Software/team">Team</a> | ||
Line 348: | Line 334: | ||
<li><a href="https://2011.igem.org/Team:USTC-Software/members">members</a></li> | <li><a href="https://2011.igem.org/Team:USTC-Software/members">members</a></li> | ||
<li><a href="https://2011.igem.org/Team:USTC-Software/collaboration">collaboration</a></li> | <li><a href="https://2011.igem.org/Team:USTC-Software/collaboration">collaboration</a></li> | ||
- | <li><a href="https://2011.igem.org/Team:USTC-Software/attribution">attribution</a></li> | + | <li><a href="https://2011.igem.org/Team:USTC-Software/attribution">attribution & contributions</a></li> |
<li><a href="https://2011.igem.org/Team:USTC-Software/acknowledgements">acknowledgements</a></li> | <li><a href="https://2011.igem.org/Team:USTC-Software/acknowledgements">acknowledgements</a></li> | ||
</ul> | </ul> | ||
Line 373: | Line 359: | ||
<div id="content_wrapper"> | <div id="content_wrapper"> | ||
- | < | + | <div id="intro"> |
- | + | <p> Contents: | |
- | + | <ul type="square"> | |
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | <p> | + | |
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | < | + | |
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
+ | <li><a href="#Algorithm"> Algorithm </a></li> | ||
+ | |||
+ | <ul type="circle"> | ||
+ | <li><a href="#Particle swarm optimization (PSO) Algorithm">Particle swarm optimization (PSO) Algorithm</a></li> | ||
+ | |||
+ | <ul type="disc"> | ||
+ | <li><a href="#History">History</a></li> | ||
+ | <li><a href="#Algorithm introduction">Algorithm introduction</a></li> | ||
+ | <li><a href="#Application">Application</a></li> | ||
+ | </ul> | ||
+ | </ul> | ||
+ | |||
+ | <ul type="circle"> | ||
+ | <li><a href="#Simulated Annealing(SA) Algorithm">Simulated Annealing(SA) Algorithm</a></li> | ||
+ | <ul type="disc"> | ||
+ | <li><a href="#Principle of the algorithm">Principle of the algorithm</a></li> | ||
+ | <li><a href="#Steps">Steps</a></li> | ||
+ | <li><a href="#State transition">State transition</a></li> | ||
+ | <li><a href="#Probability function of the state transition">Probability function of the state transition</a></li> | ||
+ | </ul> | ||
+ | </ul> | ||
+ | |||
+ | <ul type="circle"> | ||
+ | <li><a href="#MoDeL">MoDeL</a></li> | ||
+ | </ul> | ||
+ | </ul> | ||
+ | </p> | ||
+ | |||
+ | </div> | ||
+ | <h2><a name="Particle swarm optimization (PSO) Algorithm" id="Particle swarm optimization (PSO) Algorithm"></a>Particle swarm optimization (PSO) Algorithm</h2> | ||
+ | <h3><a name="History" id="History"></a>History</h3> | ||
+ | <p>Particle swarm optimization (PSO) is a population based stochastic optimization technique developed by Dr. Eberhart and Dr. Kennedy in 1995, | ||
+ | inspired by social behavior of bird flocking or fish schooling. The particle swarm concept originated as a simulation of simplified social system. | ||
+ | The original intent was to graphically simulate the choreography of bird of a bird block or fish school. | ||
+ | However, it was found that particle swarm model can be used as an optimizer. </p> | ||
+ | |||
+ | <h3><a name="Algorithm introduction" id="Algorithm introduction"></a>Algorithm introduction</h3> | ||
+ | |||
+ | <p>Each particle keeps track of its coordinates in the problem space which are associated with the best solution (fitness) it has achieved so far. (The fitness value is also stored.) | ||
+ | This value is called pbest. Another "best" value that is tracked by the particle swarm optimizer is the best value, obtained so far by any particle in the neighbors of the particle. | ||
+ | This location is called lbest. when a particle takes all the population as its topological neighbors, the best value is a global best and is called gbest. </p> | ||
+ | |||
+ | <p>The particle swarm optimization concept consists of, at each time step, changing the velocity of (accelerating) each particle toward its pbest and lbest locations (local version of PSO). | ||
+ | Acceleration is weighted by a random term, with separate random numbers being generated for acceleration toward pbest and lbest locations.</p> | ||
+ | |||
+ | <img src="https://static.igem.org/mediawiki/2011/e/ec/USTC_Software_PSO.jpg" /> | ||
+ | |||
+ | <h3><a name="Application" id="Application"></a>Application</h3> | ||
+ | |||
+ | <p>PSO has been successfully applied in many research and application areas. | ||
+ | It is demonstrated that PSO gets better results in a faster, cheaper way compared with other methods.</p> | ||
+ | |||
+ | <h2><a name="Simulated Annealing(SA) Algorithm" id="Simulated Annealing(SA) Algorithm"></a>Simulated Annealing(SA) Algorithm </h2> | ||
+ | <p>Simulated annealing (SA) is a generic probabilistic metaheuristic for the global optimization problem of locating a good approximation to the global optimum of a given function in a large search space. It is often used when the search space is discrete (e.g., all tours that visit a given set of cities). | ||
+ | For certain problems, simulated annealing may be more efficient than exhaustive enumeration — provided that the goal is merely to find an acceptably good solution in a fixed amount of time, rather than the best possible solution.</p> | ||
+ | <h3><a name="Principle of the algorithm" id="Principle of the algorithm"></a>Principle of the algorithm</h3> | ||
+ | <p>In the simulated annealing (SA) method, each point s of the search space is analogous to a state of some physical system, and the function E(s) to be minimized is analogous to the internal energy of the system in that state. | ||
+ | The goal is to bring the system, from an arbitrary initial state, to a state with the minimum possible energy.</p> | ||
+ | <h3><a name="Steps" id="Steps"></a>Steps</h3> | ||
+ | <p>At each step, the SA heuristic considers some neighbouring state s' of the current state s, and probabilistically decides between moving the system to state s' or staying in state s. These probabilities ultimately lead the system to move to states of lower energy. | ||
+ | Typically this step is repeated until the system reaches a state that is good enough for the application, or until a given computation budget has been exhausted.</p> | ||
+ | <h3><a name="State transition" id="State transition"></a>State transition</h3> | ||
+ | <p>The neighbours of a state are new states of the problem that are produced after altering the given state in some particular way. For example, in the traveling salesman problem, each state is typically defined as a particular permutation of the cities to be visited. The neighbours of some particular permutation are the permutations that are produced for example by interchanging a pair of adjacent cities. | ||
+ | The action taken to alter the solution in order to find neighbouring solutions is called "move" and different "moves" give different neighbours. These moves usually result in minimal alterations of the solution, as the previous example depicts, in order to help an algorithm to optimize the solution to the maximum extent and also to retain the already optimum parts of the solution and affect only the suboptimum parts. | ||
+ | In the previous example, the parts of the solution are the parts of the tour.</p> | ||
+ | <h3><a name="Probability function of the state transition" id="Probability function of the state transition"></a>Probability function of the state transition</h3> | ||
+ | <p>The probability of making the transition from the current state s to a candidate new state s' is specified by an acceptance probability function P(e,e',T), that depends on the energies e = E(s) and e' = E(s') of the two states, and on a global time-varying parameter T called the temperature. States with a smaller energy are better than those with a greater energy. The probability function P must be positive even when e' is greater than e. | ||
+ | This feature prevents the method from becoming stuck at a local minimum that is worse than the global one.</p> | ||
+ | <img src="https://static.igem.org/mediawiki/2011/3/32/USTC_Software_SA.jpg" /> | ||
+ | <h2><a name="MoDeL" id="MoDeL"></a>MoDeL</h2> | ||
+ | <p>The Perl language is a powerful tool for dealing with regular expressions, and it manages to process complex problems in a timely way. For example, for a hash array with a few elements in the buckets almost get the same manipulating time with a big hash with millions of elements. This feature improves the speed of rule based modeling remarkably.</p> | ||
+ | <p>Dealing with regular expressions is also Perl's cup of tea. So the software can spend more running time saved by perl on providing a better user's interface, making it more convenient for users.</p> | ||
+ | <p>Our approach first realized by Liaochen and 2010igemers emphasize on the structure of the species.</p> | ||
- | < | + | <p>Here is a detailed explanation to the input file of the rule based modeling approach |
+ | There are four blocks, respectively lists the definition of parameters, the definition of compartments, seed species and events.</p> | ||
+ | <p>The definition of parameters consists of two items. The left side term is the name of the variable, to the right is the expression of that parameter. Note that variables in that expression must be defined by the user. But it makes no difference whether they are defined before the expression. This is to avoid redundant definition and no definition. </p> | ||
+ | <br /> | ||
+ | <p>The compartments definition is in this way: <br/> | ||
+ | [name ][outside][ruletable]{volume}{population}, where terms in the square brackets are mandatory, while terms in the curly braces are optional.<br/> | ||
+ | The default value of the volume is 1. The outside term means the compartment outside the compartment, which is usually the medium that held the compartment like the ecoli. <br/> | ||
+ | Ruletable is used to associate a rule in the data base with the compartment. </p> | ||
+ | <br /> | ||
- | < | + | <p>The third block, reads [compartment][name][structure][init_concentration]{const}, structure is the definition of the complex structure, const is optional since it's in the curly brace. If the substance has a const property, then after the substance, write a const. if not, leave it blank.</p> |
- | <p> | + | <p>The last block is the events definition. The formats are [name][trigger_condition][event_assignments...] |
+ | The name of the event is usr defined, trigger_condition is a bool expression, all the variables inside this bool expression must have been defined in one of the above three blocks. Event_assignments is a list of assignments, something like assignment1 assignment2 assignment3, with white space separated. There is no constraint on the number of assignments. Each assignment must be the format [variable]=[expression]</p> | ||
- | <p> | + | <p>A general rule in the algorithm is that the name of the variable must be started by A-Z –z and other characters can be A-Z-a-z-0-9.</p> |
- | |||
- | < | + | <h2>iGAME</h2> |
- | < | + | <p>According to the rule-based languages, such as BNGL[1,2] and Kappa Language[3], molecules are |
+ | represented with structured objects comprised of agents that can take any number of sites. | ||
+ | Bonds could be formed by connecting sites on different agents to group them together and | ||
+ | form complex. Typically, sites represent functional physical entities of various kinds of | ||
+ | molecules, such as DNA-binding domains and promoter regions. Besides serving as terminal | ||
+ | ends of bonds, sites can also take on any number of labels representing its internal states. | ||
+ | Labels can be phosphorylation/unphorsphorylation status of proteins and open/close status | ||
+ | of a complex of RNA polymerase and a promoter. Biological processes between agents can be | ||
+ | easily and conveniently represented by the changes of their sites on the binding | ||
+ | status and labels. An example of Lac dimer is given to briefly illustrate the syntax | ||
+ | of this representation. Each Lac repressor, LacR, has one dimerization domain dim and | ||
+ | can thus be written as LacR(dim). By connecting the two dim domains of two LacRs, | ||
+ | the Lac dimer is then represented as LacR(dim!1).LacR(dim!1), where `.' separates different agents | ||
+ | and the same number following `!' shared by two dim domains indicates a bond formation | ||
+ | between them. The essences of those languages are preserved in MoDeL but with some major changes | ||
+ | to make it better suited to describe synthetic biological systems.</p> | ||
+ | <br/> | ||
- | <p> | + | <p>Synthetic biological systems are mostly Genetic Regulatory Networks (GRNs), in which |
+ | regulations in both transcriptional and translational level are key to control the system | ||
+ | to exhibit some complex bahaviors, such as oscillation. | ||
+ | DNA sequences composed of basic BioBrick parts (agents) are not consicely represented, | ||
+ | resulting in unreadability of the reaction rules containing such DNA sequences. In their | ||
+ | representations, each part has both upstream and downstream domain and adjacent parts are | ||
+ | connected by forming a bond between the upstream domain of one part and the downstream | ||
+ | domain of the other. In addition, all the agents in Kappa Language are allowed to appear in | ||
+ | any order so that it may blur the recognition of spatial relationship of agents; it is | ||
+ | hard to pick up the agents in a DNA chain with the correct order. For example, | ||
+ | a complex of RNA polymerase binding to trp promoter (MIT registry ID K191007) with LOVTAP | ||
+ | on p2 can be rewritten as `\textbf{\small{DNA(up!2,bind,type$\sim$K191007p3), LOVTAP(dna!1), | ||
+ | DNA(bind!1,type$\sim$K191007p2,down!2), RNAP(dna,rna)}}'. However, most readers, even specialists, | ||
+ | have some difficulties to recognize and map it to the molecule it represents in a short | ||
+ | time, making the process of model contruction laborious and error-prone.</p> | ||
+ | <br/> | ||
- | <p> | + | <p>Aiming to simplify the representation of DNA and RNA sequences, we use the hyphen character `-' |
+ | to connect two adjacent BioBricks rather than through bonding between one pair of | ||
+ | upstream and downstream sites. This is good for visualization since the structure of | ||
+ | molecules pictured in this way can be understood eaisly by readers. As to the syntax | ||
+ | of single BioBrick representation, there are some minor differences with Kappa language: | ||
+ | (1) the name of each BioBrick should be the same with the identifier of that BioBrick | ||
+ | in the MIT registry; (2) the reversed sequence of each DNA BioBrick is assumed when an | ||
+ | asterik character `*' appears following its name; But the sites of each BioBrick | ||
+ | are defined in the same way as Kappa Language does and those names should be different | ||
+ | with each other indicating equivalent sites are not supported. For example, the reverse part | ||
+ | of Lac promoter (r0010) can be represented as r0010*(), where sites in the | ||
+ | parenthesis are not shown. It is worthy of nothing that the parenthesis cannot be | ||
+ | omitted even for BioBricks that do not take any sites. By convention, | ||
+ | a DNA sequence written from left to right is assumed to read from 5' end to 3' end.</p> | ||
+ | <br/> | ||
- | <p> | + | <p>As shown in the example of Lac dimer, a molecule may contain several agents as members |
+ | separated by `.', by which means an agent is the basic unit of its composition. In MoDeL, | ||
+ | the basic unit, however, has been expanded horizontally to be a sequence and | ||
+ | different sequences, also separated by `.' in the representation, constitute molecules | ||
+ | by forming bonds between them. The concept of sequence is not limited to DNA or RNA chains, | ||
+ | but can be generalized to proteins and non-BioBricks in which cases | ||
+ | each sequence may have only one agent. One example is Isopropyl beta-D-1-thiogalactopyranoside | ||
+ | (IPTG). It has a binding domain \textit{laci} for Lac repressor and thus can be | ||
+ | represented as i0001(laci), where i0001 is not a valid identifier | ||
+ | in MIT registry since IPTG is not a BioBrick part but a conceptual part in our extension, | ||
+ | which can be represented using the same syntax of BioBrick definition. In a short summary, | ||
+ | sequences are chains composed of one or more parts, which are not limited to BioBrick parts or even | ||
+ | not corresponded to any actual entities.</p> | ||
- | < | + | <br/> |
- | <p> | + | <p>There is a problem brought by the use of registry identifiers as the name of BioBricks: |
+ | in principle, protein coding sequences should also have both RNA and protein | ||
+ | representations and other type of BioBricks, such as promoters, ribosome binding sites and | ||
+ | terminators, should have RNA representations. Each BioBrick, when transcribed or translated | ||
+ | possibly, cannot be distinguished from its DNA, RNA and protein representations simply by | ||
+ | its name and a qualifier is needed to tag a sequence explicitly to tell whether it is a BioBrick | ||
+ | and if it is, which type of representation it belongs to. This can be easily done by adding | ||
+ | a type qualifier preceding a colon character `:' to the head of a sequence representation | ||
+ | to distinguish the four cases. In the current version of MoDeL, the four permitted types | ||
+ | of sequences are DNA(d), RNA(r), Protein(p) and Non-BioBricks(nb), where the character in parenthesis | ||
+ | following each type is the type qualifier used to tag sequences. For example, the tet repressor (tetR) | ||
+ | can be represented as p:c0040(dna), which is totally different with d:c0040(dna), the protein | ||
+ | coding sequence for tetR protein.</p> | ||
+ | <br/> | ||
Latest revision as of 07:59, 5 October 2011
USTC-Software
Contents:
Particle swarm optimization (PSO) Algorithm
History
Particle swarm optimization (PSO) is a population based stochastic optimization technique developed by Dr. Eberhart and Dr. Kennedy in 1995, inspired by social behavior of bird flocking or fish schooling. The particle swarm concept originated as a simulation of simplified social system. The original intent was to graphically simulate the choreography of bird of a bird block or fish school. However, it was found that particle swarm model can be used as an optimizer.
Algorithm introduction
Each particle keeps track of its coordinates in the problem space which are associated with the best solution (fitness) it has achieved so far. (The fitness value is also stored.) This value is called pbest. Another "best" value that is tracked by the particle swarm optimizer is the best value, obtained so far by any particle in the neighbors of the particle. This location is called lbest. when a particle takes all the population as its topological neighbors, the best value is a global best and is called gbest.
The particle swarm optimization concept consists of, at each time step, changing the velocity of (accelerating) each particle toward its pbest and lbest locations (local version of PSO). Acceleration is weighted by a random term, with separate random numbers being generated for acceleration toward pbest and lbest locations.
Application
PSO has been successfully applied in many research and application areas. It is demonstrated that PSO gets better results in a faster, cheaper way compared with other methods.
Simulated Annealing(SA) Algorithm
Simulated annealing (SA) is a generic probabilistic metaheuristic for the global optimization problem of locating a good approximation to the global optimum of a given function in a large search space. It is often used when the search space is discrete (e.g., all tours that visit a given set of cities). For certain problems, simulated annealing may be more efficient than exhaustive enumeration — provided that the goal is merely to find an acceptably good solution in a fixed amount of time, rather than the best possible solution.
Principle of the algorithm
In the simulated annealing (SA) method, each point s of the search space is analogous to a state of some physical system, and the function E(s) to be minimized is analogous to the internal energy of the system in that state. The goal is to bring the system, from an arbitrary initial state, to a state with the minimum possible energy.
Steps
At each step, the SA heuristic considers some neighbouring state s' of the current state s, and probabilistically decides between moving the system to state s' or staying in state s. These probabilities ultimately lead the system to move to states of lower energy. Typically this step is repeated until the system reaches a state that is good enough for the application, or until a given computation budget has been exhausted.
State transition
The neighbours of a state are new states of the problem that are produced after altering the given state in some particular way. For example, in the traveling salesman problem, each state is typically defined as a particular permutation of the cities to be visited. The neighbours of some particular permutation are the permutations that are produced for example by interchanging a pair of adjacent cities. The action taken to alter the solution in order to find neighbouring solutions is called "move" and different "moves" give different neighbours. These moves usually result in minimal alterations of the solution, as the previous example depicts, in order to help an algorithm to optimize the solution to the maximum extent and also to retain the already optimum parts of the solution and affect only the suboptimum parts. In the previous example, the parts of the solution are the parts of the tour.
Probability function of the state transition
The probability of making the transition from the current state s to a candidate new state s' is specified by an acceptance probability function P(e,e',T), that depends on the energies e = E(s) and e' = E(s') of the two states, and on a global time-varying parameter T called the temperature. States with a smaller energy are better than those with a greater energy. The probability function P must be positive even when e' is greater than e. This feature prevents the method from becoming stuck at a local minimum that is worse than the global one.
MoDeL
The Perl language is a powerful tool for dealing with regular expressions, and it manages to process complex problems in a timely way. For example, for a hash array with a few elements in the buckets almost get the same manipulating time with a big hash with millions of elements. This feature improves the speed of rule based modeling remarkably.
Dealing with regular expressions is also Perl's cup of tea. So the software can spend more running time saved by perl on providing a better user's interface, making it more convenient for users.
Our approach first realized by Liaochen and 2010igemers emphasize on the structure of the species.
Here is a detailed explanation to the input file of the rule based modeling approach There are four blocks, respectively lists the definition of parameters, the definition of compartments, seed species and events.
The definition of parameters consists of two items. The left side term is the name of the variable, to the right is the expression of that parameter. Note that variables in that expression must be defined by the user. But it makes no difference whether they are defined before the expression. This is to avoid redundant definition and no definition.
The compartments definition is in this way:
[name ][outside][ruletable]{volume}{population}, where terms in the square brackets are mandatory, while terms in the curly braces are optional.
The default value of the volume is 1. The outside term means the compartment outside the compartment, which is usually the medium that held the compartment like the ecoli.
Ruletable is used to associate a rule in the data base with the compartment.
The third block, reads [compartment][name][structure][init_concentration]{const}, structure is the definition of the complex structure, const is optional since it's in the curly brace. If the substance has a const property, then after the substance, write a const. if not, leave it blank.
The last block is the events definition. The formats are [name][trigger_condition][event_assignments...] The name of the event is usr defined, trigger_condition is a bool expression, all the variables inside this bool expression must have been defined in one of the above three blocks. Event_assignments is a list of assignments, something like assignment1 assignment2 assignment3, with white space separated. There is no constraint on the number of assignments. Each assignment must be the format [variable]=[expression]
A general rule in the algorithm is that the name of the variable must be started by A-Z –z and other characters can be A-Z-a-z-0-9.
iGAME
According to the rule-based languages, such as BNGL[1,2] and Kappa Language[3], molecules are represented with structured objects comprised of agents that can take any number of sites. Bonds could be formed by connecting sites on different agents to group them together and form complex. Typically, sites represent functional physical entities of various kinds of molecules, such as DNA-binding domains and promoter regions. Besides serving as terminal ends of bonds, sites can also take on any number of labels representing its internal states. Labels can be phosphorylation/unphorsphorylation status of proteins and open/close status of a complex of RNA polymerase and a promoter. Biological processes between agents can be easily and conveniently represented by the changes of their sites on the binding status and labels. An example of Lac dimer is given to briefly illustrate the syntax of this representation. Each Lac repressor, LacR, has one dimerization domain dim and can thus be written as LacR(dim). By connecting the two dim domains of two LacRs, the Lac dimer is then represented as LacR(dim!1).LacR(dim!1), where `.' separates different agents and the same number following `!' shared by two dim domains indicates a bond formation between them. The essences of those languages are preserved in MoDeL but with some major changes to make it better suited to describe synthetic biological systems.
Synthetic biological systems are mostly Genetic Regulatory Networks (GRNs), in which regulations in both transcriptional and translational level are key to control the system to exhibit some complex bahaviors, such as oscillation. DNA sequences composed of basic BioBrick parts (agents) are not consicely represented, resulting in unreadability of the reaction rules containing such DNA sequences. In their representations, each part has both upstream and downstream domain and adjacent parts are connected by forming a bond between the upstream domain of one part and the downstream domain of the other. In addition, all the agents in Kappa Language are allowed to appear in any order so that it may blur the recognition of spatial relationship of agents; it is hard to pick up the agents in a DNA chain with the correct order. For example, a complex of RNA polymerase binding to trp promoter (MIT registry ID K191007) with LOVTAP on p2 can be rewritten as `\textbf{\small{DNA(up!2,bind,type$\sim$K191007p3), LOVTAP(dna!1), DNA(bind!1,type$\sim$K191007p2,down!2), RNAP(dna,rna)}}'. However, most readers, even specialists, have some difficulties to recognize and map it to the molecule it represents in a short time, making the process of model contruction laborious and error-prone.
Aiming to simplify the representation of DNA and RNA sequences, we use the hyphen character `-' to connect two adjacent BioBricks rather than through bonding between one pair of upstream and downstream sites. This is good for visualization since the structure of molecules pictured in this way can be understood eaisly by readers. As to the syntax of single BioBrick representation, there are some minor differences with Kappa language: (1) the name of each BioBrick should be the same with the identifier of that BioBrick in the MIT registry; (2) the reversed sequence of each DNA BioBrick is assumed when an asterik character `*' appears following its name; But the sites of each BioBrick are defined in the same way as Kappa Language does and those names should be different with each other indicating equivalent sites are not supported. For example, the reverse part of Lac promoter (r0010) can be represented as r0010*(), where sites in the parenthesis are not shown. It is worthy of nothing that the parenthesis cannot be omitted even for BioBricks that do not take any sites. By convention, a DNA sequence written from left to right is assumed to read from 5' end to 3' end.
As shown in the example of Lac dimer, a molecule may contain several agents as members separated by `.', by which means an agent is the basic unit of its composition. In MoDeL, the basic unit, however, has been expanded horizontally to be a sequence and different sequences, also separated by `.' in the representation, constitute molecules by forming bonds between them. The concept of sequence is not limited to DNA or RNA chains, but can be generalized to proteins and non-BioBricks in which cases each sequence may have only one agent. One example is Isopropyl beta-D-1-thiogalactopyranoside (IPTG). It has a binding domain \textit{laci} for Lac repressor and thus can be represented as i0001(laci), where i0001 is not a valid identifier in MIT registry since IPTG is not a BioBrick part but a conceptual part in our extension, which can be represented using the same syntax of BioBrick definition. In a short summary, sequences are chains composed of one or more parts, which are not limited to BioBrick parts or even not corresponded to any actual entities.
There is a problem brought by the use of registry identifiers as the name of BioBricks: in principle, protein coding sequences should also have both RNA and protein representations and other type of BioBricks, such as promoters, ribosome binding sites and terminators, should have RNA representations. Each BioBrick, when transcribed or translated possibly, cannot be distinguished from its DNA, RNA and protein representations simply by its name and a qualifier is needed to tag a sequence explicitly to tell whether it is a BioBrick and if it is, which type of representation it belongs to. This can be easily done by adding a type qualifier preceding a colon character `:' to the head of a sequence representation to distinguish the four cases. In the current version of MoDeL, the four permitted types of sequences are DNA(d), RNA(r), Protein(p) and Non-BioBricks(nb), where the character in parenthesis following each type is the type qualifier used to tag sequences. For example, the tet repressor (tetR) can be represented as p:c0040(dna), which is totally different with d:c0040(dna), the protein coding sequence for tetR protein.