Flux Balance Analysis (FBA) is a mathematical method for simulating metabolism in metabolic networks. It is based on linear programming to calculate fluxes when the model is stable.

Assuming S is a matrix, which contains all reactions in a model. In this matrix, metabolites consumed take negative coefficients, and metabolites produced then take positive ones. Furthermore, v is a vector that represents the flux of all reactions. When the system is steady, it satisfies: $$ \textbf{S}\textbf{v}=0 $$ And then, FBA tries to maximize or minimize the objective function \(\textbf{c}^\textrm{T} \textbf{v}\), which c contains the weight of all reactions contributing to the function. Now it is clear that FBA is a linear programming problem, and it just works.

Flux Variability Analysis (FVA) is an extension of FBA. It can show the minimum and maximum range of each reaction flux while they satisfy constraints and have the same optimal objective by solving a double linear programming problem.

However, when the metabolic network contains internal loops, the result can be too high in absolute to be realistic. Users can select the "loopless" option to avoid such internal loops, and get a more consistent result.

Object-Relational Mapping (ORM) enables us to work with databases more comfortable and safer. It fills the gap between object-oriented programming languages and relational databases and avoids the vulnerability of SQL Injection.

We use ORM to organize our metabolic networks, biobricks data, and user's computational models. It brings us the convenience of creating, querying, listing, and connecting models, with acceptable performance.

In practice, we use Django ORM with MySQL backend to provide fast, flexible, and reliable service.

Our website requires computing large models, and it is quite embarrassing to see users waiting for browsers for so long. So we use message queues to maintain computing tasks.

We split our programs computing models from our website, and use message queues to send and receive information about our computation. A queue is a data structure that stores things waiting to be handled, and it obeys the "First Come, First Serve" principle. So, we can store our computing tasks in the queue, and response to users instantly about the progress of his tasks.

In Foresyn, we use RabbitMQ and Celery to build our message queues. Here, Celery uses its protocol to communicate with web programs and computation programs. And RabbitMQ acts as a broker who accepts and forwards messages of Celery.

When we are developing Foresyn, we discovered that there is a contradiction between speed and accuracy. So our strategy is to use slow but accurate algorithm when searching small datasets, and use fast but less accurate algorithm when searching large ones.

Here, there are only some models like E. coli, but a lot of genes, reactions and metabolites in our database. We choose to calculate Levenshtein distances for model searching. Levenshtein distance defines as the following recursive function: $$ \qquad\operatorname{lev}_{a,b}(i,j) = \begin{cases} \max(i,j) & \text{if } \min(i,j)=0, \\ \min (\operatorname{lev}_{a,b}(i-1,j) + 1,\operatorname{lev}_{a,b}(i,j-1) + 1, \operatorname{lev}_{a,b}(i-1,j-1) + 1) & a_i \neq b_i, \\ \min (\operatorname{lev}_{a,b}(i-1,j) + 1,\operatorname{lev}_{a,b}(i,j-1) + 1, \operatorname{lev}_{a,b}(i-1,j-1)) & \text{otherwise.} \\ \end{cases} $$ which has a time complexity of \(O(nm)\) where n and m are the length of the two strings.

When we are handling genes, reactions and metabolites, we use another algorithm.

TBD