The Sbml Ode Solver Library Support Requests 10 Build
By making use of the BioChem library, SystemModeler lets you build, simulate, and visualize PKPD and systems biology models. With graphical notation system. CellDesigner supports simulation and parameter scan by an integration with SBML ODE Solver and Copasi. By using CellDesigner, users can browse and modify existing SBML models with. The other SBML versions are automatically generated and provided for convenience, as certain tools support only some specific levels or versions of SBML. The menu Other formats ( auto - generated ) provides access to other model representation formats, such as BioPAX ( see Note 10 ) (level 2 and level 3) [ 16 ] and the Virtual Cell Markup Language (VCML) [ 17 ]. This article describes an efficient algorithm to solve SBML models that are interpreted in terms of ordinary differential equations. We begin our consideration with a formal representation of the mathematical form of the models and explain all parts of the algorithm in detail, including several preprocessing steps.
You can subscribe to this list. 2005 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2006 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2007 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2008 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2009 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2010 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2011 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2014 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec S M T W T F S 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31. Hi, Rainer wrote: Hi Benmoving this discussion to the list, in case anyone else is interested. On Mon, 2009-09-28 at 11:33 -0400, Ben Allan wrote: I'm glad to hear there's still an active community around SOSlib. I'm working on a project which really wants to provide its own drivers for montecarlo and ode/dae solutions, but to use the fairly nice model evaluation engine you all have developed. So you are only interested in the SBML - ODEModel part, but not the Sundials wrapper, correct? The current sundials wrapper is sufficiently entangled with the model that it's hard to persuade the customer that it would be easy to bring into the code base and maintain.
We're also fairly expert in sundials locally, so the inclination is to reinvent (and in some cases to use something other than sundials). It would be really nice if there was a clean rootstopping dae model interface defined, but it appear we would need to contribute that.
Two things, first for the SBML - ODEModel: we plan to formalize that approach, and introduce a stoichiometryMatrix object as an intermediate between SBML and ODE system. This should allow easier integration with reaction-network-based model reduction algorithms, or general reaction network analysis tools. Don't know if you would be interested in this topic too. Probably most of these algorithms already exist somewhere with SBML-to-SBML interfaces, but I think it would be a natural extension for SOSlib.
The Sbml Ode Solver Library Support Requests 10 Building
I like the idea of exposing the stoichiometry matrix and the list of rates-of-progress (instead of just the RHS of the ode/dae). Second a bit of advertising for the integrator part of SOSlib - although from what you say, you probably really want to use your own solver wrappers. Anyways, we do have a separate library which for unresolved licensing issues is not part of SOSlib (yet?), but uses our sundials wrappers for efficient parameter estimation (fitting experimental data stored in the same format as the soslib's commandline tool odeSolver output), both global and local.
Once the error handling is moved to isntances instead of global, all should be set up for nice parallel usage. As you say, licensing issues. And of course the research content isn't solving ode's, the research is in solving ugly parameter estimation problems. The research is really in the modeling and results, not in the numerical engines, but people always seem to get caught up in hiding their easy to reinvent source code hoping to make money off it somehow.
A little report on what i've done so far in modifying the code in my copy: getting it to work with libsbml 4 (2.4 sbml spec). Nice, are there many changes required? Several places where libsbml now expects to be passed 2 integer arguments (e.g.
Modelcreate(2,4); // version 2.4 sbml I'll post a diff eventually. It also has added a feature for the modeler to tell the solvers when a model is stiff (fast reactions) and the integrator needs to be tuned accordingly. We once had a complete separation of structures, but due to some problems with compilation we got rid of it again. Can't remember what the problem exactly was, but in principle we wouldn't mind splitting into public and private headers again. I've done so. I'm working on (may have completed today) being able to call on your odeModel without seeing all the tangled details of your cvode and code generator headers.
The key to this is a style they use well in libsbml- create a header which forward declares all the public struct typedefs without exposing the struct contents. All the public functions requiring pointers to these types are happy at compile time now.
This style cannot be used to hide the contents of an enum- I found that commented about in your code someplace. But the enums aren't particularly needed outside soslib as far as I can tell. BTW, we have biology, chemistry, physics and mathematics backgroundresp., so there is no dedicated computer scientist involved. Andrew Finney was the computer scientist (involved in SBML and libSBML once) who pushed the whole thing towards a library and would also have preferred C interfaces. Unfortunately none of us really speaks C currently. But especially the interfaces (input settings and result structures) would probably be much easier to maintain and wrap in C.
CUDA sound great. C doesn't have to be at all un-C-like- see libsbml for a nice clean example of an fairly complex interface that looks nice in c and c and html. On a different project I have a bunch of people who think in fortran and write correspondingly fortran-like c; you can use as little of c as you like in a given project. Sourceforge repository is master. Do you want developer access? I'd have to wait for internal discussion though. And in principle significant changes should be discussed on the list before submitting of course.
Especially since you clearly have your own development schedule, I suspect the only way to proceed sanely would be making an alternate c-friendly version directory in your repository. You could then look at the code I put in and decide which features you want to migrate to your main code. I could (and if requested will) just post a patch file to the mailing list or privately, but it's getting to be a pretty big patch.
You can find me elsewhere on sourceforge under the id ballan (cca-forum, bocca). Would you be interested in splitting soslib internally (or publically) into an smbl evaluation engine library with a separate library of integrations/statistical methods on top of it? Do you mean separate packages and build structures for these functionalities, or separate CVS branches? I wouldn't know how that works. In principle, we wouldn't oppose splitting into two libraries. As mentioned above, we have plans for extending the SBMLODE part and linking it with pure reaction network analysis, separate from the sundials wrappers, and on the other hand we already have an additional separate library build on top of the sundials integration and like to keep it general.
Making it more modular is certainly in our interest. But as said in the first email, our main limitation currently is time:( That's where open-source comes in- free time obtained from other people. I'm in the process of splitting out the odemodel and friends and can contribute all that back if someone will use it or if you're simply willing to host it for others even if you're unwilling to use it. I can/will test all that change against odeSolver and examples/ before committing it anywhere, but obviously I can't test or update other dependent code which isn't in the public repository. So if one tried to use my new stuff with the non-public dependent code, it would all be 'broken' and the typical gut reaction would be 'ah, the new guy just writes crap'.
For plain old c (and c) simply splitting models and solvers into separate directories (sharing only opaque pointer types) could be fairly simple. The change to the build system would be fairly small. You.might. chose to use a CVS branch for this, but I'm not a big fan of CVS branches- cvs doesn't really provide enough support for branching, compared to SVN and newer systems. Thanks Ben Allan.