sys-bio / roadrunner

libRoadRunner: A high-performance SBML simulator
http://libroadrunner.org/
Other
39 stars 25 forks source link

Delay differential equation with constant delay #303

Open matthiaskoenig opened 8 years ago

matthiaskoenig commented 8 years ago

Hi all,

in the near future I will work a lot with PKPD models, mainly in the context of coupling cellular/tissue/organ models with whole-body models. A first review of existing models showed that most of them have at least one/two delayed differential equations (constant delays). It would be amazing if this could be handled in roadrunner.

A simple example model can be found in the SBML specification L3V1 (7-10).

The implementation of the constant delay should be not to complicated in cvode http://sundials.2283335.n4.nabble.com/Implementing-ODE-s-with-delay-td3240846.html

I opened a discussion on libsbml https://groups.google.com/forum/#!topic/libsbml-development/v13NATE1gVQ

It could also be interesting to extend sbml2matlab to export the delay equations for dde23 to have at least a way to simulate such models right now.

Matthias

hsauro commented 8 years ago

You're right it would be nice to have but how would one handle events?

Herbert

luciansmith commented 8 years ago

For delay differential equations, you either have to keep track of what X's values were N seconds ago, or be able to calculate them. I think a typical way to do this is to just store the values you need to know about as you calculate them, so you can look up what they used to be when you need to. Another possibility (for constant delay) is to parallelly simulate a N-second delayed version of the model, that the first model can look at when it needs to. In the case of stochasticity, both obviously need to be seeded with the same value.

In both cases, events fall out as part of the normal course of things: if you're recording what values X had in the past, any event that affected X is simply recorded. If you have a parallel N-second delayed version of the model, that model will also have events in it that will proceed normally.

-Lucian​

0u812 commented 8 years ago

I think we need to nail down the requirements more. In the thread that Matthias linked, there's a split among people who think SUNDIALS is "good enough" and people who think you should use a dedicated DDE solver. Whether you can get away with using SUNDIALS (coupled with N-second delay memory) or not depends on several factors:

matthiaskoenig commented 8 years ago

constant delays: yes at least for the models I am interested in there are only constant delays. Using constant delay equations is one of the tricks in the PKPD modelling to get the correct system behavior. These consist mainly a set of coupled compartments (which represent the different organs) and the appearance (disappearance) kinetics in the different organs of substances depend often time delayed on the concentration in a different compartment. I wanted to encode a handful of such models in SBML, which could be used as test cases.

accuracy: yes important (but interpolation between data points is sufficient) One can always increase the tolerance of the solver if necessary and not sufficient (I would check this via mass balance in the total system, which includes delayed quantities. If the mass balance stays constant the error should be okay). As far as I understand it: If the steps fullfill the tolerances, than every interpolation between them should fullfill the same tolerances. At least in a good approximation if the delayed quantities are not behaving extremly eratic or are many orders larger/smaller than everything else in the system (this is not the case, because are mainly concentrations in large volumes with slow kinetics compared to the rest).

In my opinion the simple interpolation method is sufficient for all I want to simulate. To put in the work to implement SBML in a DDE solver is an overkill at this point (and they probably don't do much more than an interpolation themselves). M

matthiaskoenig commented 8 years ago

Hi all, any progress/plans for the support of constant delay equations in roadrunner?

I have to work/encode some models related to the insulin/glucose regulatory system and would love to do this in SBML + roadrunner. Most of the existing minimal models contain one/multiple constant delays in the model equations (mainly to account for the delayed suppression of hepatic glucose production via insulin). See for instance http://www.sciencedirect.com/science/article/pii/S0168927405000929 Section 3 for some examples.

With the support of constant delays I could encode everything in SBML, otherwise I have to start using the Matlab DDE solvers without SBML.

An example model is attached below.

# simple delay model
r2 = te.loada("""
model delay_model()
    T = 10;
    tau = 5;  # delay
    k1 := sin((2*pi/T)*time);
    k2 := delay(k1, tau)
end
""")

r2.timeCourseSelections += ['k1', 'k2']
s2 = r2.simulate(0,100, steps=101)
r2.plot(s2, linestyle='--', marker='o')

rr_3

Currently roadrunner just plots the incorrect results without any warnings about the delays in the model, i.e. just ignoring the delay.

Being able to simulate constant delays with roadrunner would help a lot. The best Matthias

hsauro commented 8 years ago

At the moment no, I'm waiting on further grant support to do major improvements, we're currently running under a maintenance and bug fixing regime.

luciansmith commented 3 years ago

For the record: Matthias's linked thread is dead, but survives at archive.org:

https://web.archive.org/web/20171225003330/http://sundials.2283335.n4.nabble.com/Implementing-ODE-s-with-delay-td3240846.html

matthiaskoenig commented 3 years ago

Also for the record: Still very interested in running such models. I have to mess with things such as linear chain tricks to get delays in SBML models. Having support by at least one of the big SBML simulators would be amazing. Currently only the SBML-simulation-core library supports delays but somehow buggy and slow.

CiaranWelsh commented 3 years ago

I’d be interested in having a pop at implementing such a feature.