Team:USTC Software/When

{|-
 * valign = "top"|


 * valign = "top" align = "justify" border = "0" width = "600px" bordercolor = "#F3F3F3"|

=Future Plan=

Desired Dynamics Input
Q1:
 * How can we characterize the property of our desired dynamics instead of importing time course? I mean I don't care much on the exact behavior the system perform but some key characters of the dynamics?

A1:
 * It should be referred to the selection of the evaluation function. One possible solution is to convert the time dependent function from time domain to frequency domain. Fourier transform should be introduced for its advantage of simplifying many of complicated periodic functions.


 * For other common conventions and notations, see Other conventions and Other notations below. The Fourier transform on Euclidean space is treated separately, in which the variable x often represents position and ξ momentum.



Q2:
 * The desired time course for different node are largely different in order of magnitude? Also, some results of my experiment cannot be expressed as absolute values but relative ones. How to keep the dimension of different species?

A2:
 * The data may vary significantly in dimension. And it is unfortunately true for most real-case reactions' dynamics/thermodynamics constant. Therefore we consider it to be a worthwhile trial to move all calculations to logarithmatic space to overcome the strong order-dependence of initial values of inputs. Related changes are systematical, from the substitution of variables and functions to the transformation of first order deriatives.



Restriction Input
Q1:
 * The input box and steps for users is a little complicated and even have some small requirements for the users to be capable of transform rate equations to differential equations. It has confused me a little.

A1:
 * In fact this is one of the most serious headache we are suffering for now. On one hand, we have to make the input sound and standard; on the other hand we still feel it an urgent call from our users to cut off unnecessary inputs. So far, this input box is perhaps the simplest one after discussing a lot with our USTC wet team. By proposing many possible solutions, they chose this one. After the publishing of current version, we hope feedback from users can help improve the next version.

Mathematical model
Q1:
 * The general mathematical model seems to cope with two nodes coupling together at most. How about more than two nodes?

A1:
 * In current version, we allow more than two nodes reaction function as user-defined form which requires the users to input themselves. Actually, it is easy to add more than two nodes form reaction functions in the model. But the condition of computation time and RAM space will drastically be exacerbated as long as the interaction is related to more than three units. For the next version, we will change our data structure to accommodate more types but more efficient.


 * Meanwhile, we do believe the 'two-body' approximation to be a moderately acceptable choice. With reference to the classical way physists dealing with Hamiltonian of multi-electron system, we expect the same approximation for interaction among substances - that is, all multi-substances' interaction could always be boiled down to two-body interactions.


 * One possible mathematical approach is to adopt Tylor Series expansion to shorten each term describing interactions. The physical nature of this mathematical method is nothing but exactly how two-body interactions are interwined to form multi-body interactions.



Algorithm
Q1:
 * Can this software run faster and faster?

A1:
 * Firstly, in our software, we choose and modify these best optimization algorithms carefully by comparing with possible optimization algorithm. How to improve the efficiency of optimization algorithm is an open problem in computer science and mathematics. Collaboration with experts in this field is needed.


 * Secondly, the speed is quite dependent on the performance of computer. We test these programs separately on Linux system in our high performance workstation. The result is fairly better than the test on our personal computer.


 * Thirdly, to improve the algorithm performance, parallel computing is a better choice. For this reason, the algorithms we adopt are parallel in nature and extension to parallel algorithm is possible. In the future, we will rewrite our software this form via MPI.

Q2:
 * Can this software run more and more precisely?

A2:
 * The imprecision is largely caused by Local minimum and initial value dependence. Similar as above, these are also open problems. For we adopt Monte Carlo sampling in our algorithm, the results may vary time to time due to the randomness nature. It also remains a problem for us to solve in the future. We will make effort to modify existing algorithms or even create new one.

Output
Q1:
 * Is it better to export a graph following SBGN standard?

A1:
 * Currently, we are working on it. The basic drag-drop function has been accomplished in our software of current version. In the near future, we will complete this function.

Q2:
 * Can you export the robustness analysis along with the SBML model in one sheet?

A2:
 * It is not easy to implement such information in a single SBML file. In current version, we can realize a robustness analysis by importing a SBML file which two sheets will be generated. In next version, we will try to incorporate such information to a general form. With such change, there is also a need to modify libSBML as a result.

Database
Q1:
 * Does the database contain too little biobricks?

A1:
 * Since the concept of standard components that contain enough information is relatively new in synthetic biology. The acquisition to the information is rather difficult for us because we have to learn each bricks in detail. In the current version, we construct one that is suitable for our illustrative examples as well as our USTC wet team’s new submitted biobricks. A relatively “full” database needs collaborations of different teams who should submit information of the same format. Otherwise, we propose a developing standard for such a design.

Q2:
 * Is the search algorithm fast enough for the database?

A2:
 * For lager database, searching algorithm is quite important. It is also an open problem in computer science. To our extent, we seek collaborations inside or outside our campus.

Q3:
 * How do you manage these data efficiently?

A3:
 * To manage a large database, manage software is needed. Luckily, Berkeley tools team are focusing on this problem. We are expecting cooperation with them.

Q4:
 * Is it too difficult to obtain the kinetic parameters and reaction type?

A4:
 * Firstly, in the next version, we will make a web server that makes our database open access. Then users can freely update the database by submitting the data in a general form.

Secondly, we can also apply a text mining technique to get detailed information for published papers.

Link to SBW
Q1:
 * Why not incorporate SBW in this software to make it more powerful？

A1:
 * As SBML has become a standard description format for modeling a biological system. Considering the output of our design obeys this standard, a combination with SBW tools such as cell designer should be incorporated in our software for analysis and simulation purpose. We have left a button “SBW” and have written the interface template in our software.


 * valign = "top"|


 * }
 * }