-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Simulation with negative start time does not work #411
Comments
Are there examples that actually use this? I tend to think that this might
be a problem with the SED-ML spec.
…-Lucian
|
Is there a use case for having negative start times?
Herbert
…On Mon, Sep 18, 2017 at 8:09 AM Matthias König ***@***.***> wrote:
It is valid to run simulations from a negative start time (start is only
how the value is called which corresponds to the the start of the
simulation). I.e. if I want a plot from -20 to 0 this is completely valid,
but does not work in roadunner:
r.simulate(start=-20, end=0, steps=10)
~/envs/tellurium/lib/python3.5/site-packages/roadrunner/roadrunner.py in simulate(self, start, end, points, selections, steps)
3577 o.steps = steps
3578
-> 3579 result = self._simulate(o)
3580
3581 o.steps = originalSteps
~/envs/tellurium/lib/python3.5/site-packages/roadrunner/roadrunner.py in _simulate(self, opt)
3330
3331 def _simulate(self, opt):
-> 3332 return _roadrunner.RoadRunner__simulate(self, opt)
3333
3334 def getValue(self, *args):
RuntimeError: duration, startTime and steps must be non-negative
The only requirement is that start <= end, but not non-negativity.
This is needed for SED-ML simulations which use negative start times in
combination with offsets.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#411>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABAZDq0Uk5glgCTpYf3V9jcszTMzU3Foks5sjodUgaJpZM4PbDuh>
.
|
Yes, use case is here:
There should be a initial integration duration of 20 which should not be depicted in the figure (the initial phase to oscillations), but the start time of the plot should be at 0. This also often happens in experimental data where the pre-intervention phase is negative (for instance -100 to 0, than intervention is given from 0 to 10. The simulation would start at negative times and the trigger for an intervention event would be triggered at 0. |
And specification looks good. It does not exclude negative start times. 2.4.3.3.1 initialTime 2.4.3.3.2 outputStartTime |
This is really problematic, because 'time' has a specific meaning in an SBML model, and by definition in SBML, starts at 0 at the start of the simulation. If the model uses csymbol 'time' in it, it will mean 'the variable that starts at 0 at the beginning of the simulation'. CellML could handle this, since in that language, 'time' is a variable just like any other, and if you want to set its initial value to -20, you just set it. But there's no way to set the csymbol 'time' in SBML. You could fake it well enough if you ran the simulation as if -20 was 0, and then shifted the results back 20. You could do this entirely on the Tellurium side: it would take the input 'run from -20 to 50', tell roadrunner 'run from 0 to 70', then subtract 20 from the 'time' column of data. This would work for all models that don't use csymbol 'time' in them. But it would fail (or at least behave differently from CellML) for any models that did. Maybe have Tellurium issue a warning for all SED-ML that requests a negative start time if the model contains csymbol 'time'? |
Yes, I understood the -20 as a simple time shift. I.e. start and end time
of the simulation only define the duration for the simulator, independent
of these values the model is run from 0 to duration=(end-start).
The resulting time vector is than shifted to start at start (for instance
at -20).
I assume the same is happening for setting a positive start value for
instance 20 right now in roadrunner, so I don't understand why the same is
not possible to do for -20. Just shift the time vector to -20 instead of to
20.
In summary
r.simulate(start=0, end=20, steps=100)
r.simulate(start=20, end=40, steps=100)
r.simulate(start=-20, end=0, steps=100)
Should give the exact same numerical results, only the time vector is
shifted to the start time.
@lucian "t starts at 0 at the beginning of the simulation" is the same
issue for +20 shifts which are currently supported by roadrunner.
…On Mon, Sep 18, 2017 at 7:04 PM, Lucian Smith ***@***.***> wrote:
This is really problematic, because 'time' has a specific meaning in an
SBML model, and by definition in SBML, starts at 0 at the start of the
simulation. If the model uses csymbol 'time' in it, it will mean 'the
variable that starts at 0 at the beginning of the simulation'. CellML could
handle this, since in that language, 'time' is a variable just like any
other, and if you want to set its initial value to -20, you just set it.
But there's no way to set the csymbol 'time' in SBML.
You could fake it well enough if you ran the simulation as if -20 was 0,
and then shifted the *results* back 20. You could do this entirely on the
Tellurium side: it would take the input 'run from -20 to 50', tell
roadrunner 'run from 0 to 70', then subtract 20 from the 'time' column of
data. This would work for all models that don't use csymbol 'time' in them.
But it would fail (or at least behave differently from CellML) for any
models that did. Maybe have Tellurium issue a warning for all SED-ML that
requests a negative start time if the model contains csymbol 'time'?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#411 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA29ulnHXUiTi5TlpJ_9JngIbtiQBVYuks5sjqKpgaJpZM4PbDuh>
.
--
Dr. Matthias König
Junior Group Leader LiSyM - Systems Medicine of the Liver
Humboldt-University Berlin, Institute of Biology, Institute for Theoretical
Biology
https://www.livermetabolism.com
konigmatt@googlemail.com
Tel: +49 30 20938450
Tel: +49 176 81168480
|
If that's the case, the fix should be pretty simple. We can simply store the initial delta T, simulate from 0 nonetheless, and add delta T at the end to time vector. |
I still worry that both the -20 and the +20 solutions are not what was intended by SED-ML, but I suppose as early adopters of the spec, we have a say in what the spec means--if we're setting up the SED-ML test suite by default, everyone else has to do it our way ;-) |
As a followup: discussed this with the editors, and this solution is indeed the correct one: whatever state the model is in is assumed to be the 'initial state', and if 'time' is supposed to be -20 or +20 or whatever, it must itself deal with the fact that the csymbol 'time' in SBML means 'time from the simulation initial state', and add a delta itself. (i.e. it's a modeling issue, not a software issue.) |
Good to here that. I will implement this solution asap. |
This reverts commit ea98bb7.
thanks |
As Lucian pointed out, this causes problems with events etc. (#425). |
I wonder if we could solve this by splitting 'time' into two columns: something like 'internal time' and 'simulation time'. You would treat 'internal time' by leaving it as-is, and it would start with zero and end wherever. Then 'simulation time' would be offset by the required SED-ML shift. (The shift is not supposed to affect the internals of the model at all, including events, etc. But it will look weird if you know your event trigger is 'time>5' and it fires at time="-3". |
Should the 5 in time>=5 be relative to the current time or should it be the
absolute time. If it were the absolute time it would work.
What does the SBML spec say?
If time is meant to be absolute then I guess we're interpreting it wrongly?
Herbert
…On Wed, Oct 11, 2017 at 5:09 PM, Kiri Choi ***@***.***> wrote:
This is indeed problematic when dealing with events. Not only that, it's
already a problem when starting simulation from time points other than 0.
E.g. when you run:
r = te.loada("""
model mymodel()
var species X = 10
at time>=5: X = 5
end
""")
result = r.simulate(3, 10)
r.plot()
[image: image]
<https://user-images.githubusercontent.com/7672320/31472790-a1d09c72-aea5-11e7-9342-d438ce208be0.png>
I am not sure whether it's feasible, but one way to solve this issue might
be adding
delta T = 0 - starttime
to all time values specified in events and apply the previously proposed
solution.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#411 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABAZDu8_OBLpuaqSdyBf-1HQ5_GBPqj-ks5srVibgaJpZM4PbDuh>
.
|
Reading SBML spec, it seems like time is actually treated as an absolute value. That means not only our proposed solution is wrong, but also the way we handle simulation starting at t >0 is wrong. |
So, this is a confusing situation and I've tried to update the latest SED-ML spec to be more clear, but the upshot is: You are supposed to run your model as-is, without changing the internal 'time' at all. The assumption is that if a SED-ML file tells you to that the 'initialTime' is -20, that means that the model has already been scaled so that when the internal time is zero, the reported time should be -20. The upshot for tellurium is that SED-ML's initialTime is a post-processing step: it should be applied to roadrunner's output, not any input. You truncate your output if (and only if) the 'outputStartTime' is different from the 'initialTime'. |
OK, coming back to this after four years... From my perspective now, I think that the SED-ML decision was the wrong one: when simulating an SBML model, time starts at 0. It always has, and there's no way around it, since it's an implied variable. The call: simulate(5, 10, 50) doesn't request that simulation start at 0, but that output collection begin at 5 and go to 10. As such, a negative number as the 'start' argument cannot make sense in a roadrunner context. If SED-ML wants to declare that non-zero 'initialTime' attributes mean 'the pre-initialized state of the model as loaded' that would be a tellurium issue with interpreting SED-ML, but not anything I would want to implement as part of the 'simulate' function. For Matthias: if you want to declare that time zero is actually time -20, I would say that this is a post-processing step you could perform the data that roadrunner outputs. But since 'time' is an internal variable in an SBML model, there's no way to make roadrunner do what you want. |
Okay, this makes sense. But this should then be a validation rule/warning on SED-ML. I.e. if the model is an SBML model and simulation times are negative this is invalid. |
I looked at this yet again due to Herbert saying something, and I was wrong--our simulation start time isn't a data collecction start, but an actual 'we assume the model is set to this time' start. This in turn completely changed my perspective on what 't0' meant in an SBML model, and it made data collection with t0 < 0 actually much easier! It turned out to be difficult to get pre-time==0 events to fire correctly, but I have them working in general--still need to test more, but it's looking good: #854 |
This is now done! The only thing that doesn't work is #857 which isn't a negative-start-time specific problem. So I'm claiming this is done! It'll be in the next release. |
Also, if you have opinions on this matter, other perspectives would be helpful at sbmlteam/sbml-specifications#2 |
It is valid to run simulations from a negative start time (start is only how the value is called which corresponds to the the start of the simulation). I.e. if I want a plot from -20 to 0 this is completely valid, but does not work in roadunner:
The only requirement is that
start <= end
, but not non-negativity.This is needed for SED-ML simulations which use negative start times in combination with offsets.
The text was updated successfully, but these errors were encountered: