Menu
▾
▴
Re: [SOSlib-devel] Problem with senstivities
|
From: Rainer M. <ra...@tb...> - 2006-08-29 14:40:24
|
Hi Eryk,
I have played around a bit and am quite sure that we can blame it on
Sundials.
In the current version we don't free the cvode internal
sensitivity vectors yS, but only use the cvode reinit function. This
should be Ok - this what the ReInit should be for - but anyways I tried
with freeing instead.
I get different but still not correct results!
When resetting these internal yS values to 0, they are zero right after
that and right until calling CVodeGetSens in
IntegratorInstance_getForwardSens for the first time. But already there
they already have the strange values changing with each iteration.
It doesn't matter whether Sens ReInit or Sens is freed and a completely
new forward sensitivity structure is created: both cases yield
wrong results.
Also, I remember having tested iteration of sensitivity before the
official 1.6.0 release, and it worked fine. I started to suspect the
normal CVodeReInit which wasn't there in 1.6.0. We always completely freed
and initialized the whole solver in this version.
Thus I tested the loop with 1.6.0. And it works fine!
Ok, if above was not clear:
I strongly suspect that we have found a bug in CVODES!!
When doing a CVodeReInit, some internal structure used for sensitivity
analysis seems not to be correctly freed and used again for the next
runs, no matter whether the the CVode sensitivity structures have been
"ReInit"ialized or completely freed and created again. Both procedures
yield wrong results. The bug must somewhere between in CVodeReInit and
CVodeSensReInit
I have listed below older bugs, that should be fixed in the 2.1.1 version
of SUNDIALS, but they point to the still buggy nature of SUNDIALS
sensitivity tools.
We should probably search their email list whether this has been discussed
already or is fixed in a current version. Or whether we still might do
something wrong.
That's it so far.
Rainer
What's new in v2.1.1?
fixed bug in sensitivity computations on an order increase (when using
BDF).
What's new in v2.1.0?
fixed bug in adjustment of sensitivity Nordsieck history array on an order
decrease (when using BDF).
On Tue, 29 Aug 2006, Rainer Machne wrote:
>
> I have just tried such a loop (starting from
> examples/sensitivity.c) without changing any parameters and I also get
> these strange results!
>
> Interestingly, some symmetric relations are still there.
>
> E.g. in the example model MAPK.xml the sensitivities of species MKKK and
> MKKK_p to parameter Ki have exactly opposite (i.e. +/-) sensitivities:
>
> #time MKKK MKKK_P
>
> first run:
> 300 0.901181 -0.901181
>
> second run:
> 300 -0.49678 0.49678
>
> third run:
> 300 1.84961 -1.84961
>
> ...
> ninth run:
> 300 36.1583 -36.1583
>
> tenth run:
> 300 -60.514 60.514
>
> Interestingly, the sensitivities change their sign with each run.
>
> Rainer
>
> On Tue, 29 Aug 2006, W Eryk Wolski wrote:
>
>> I wish you wer right. Of course I have tested this by setting exactly
>> the same parameters values again and again. And the reported behaviour
>> applies also in this case. That is, the sensitvities are changing and
>> their magnitude is increasing with each new evaluation of the model
>> independently of the parameters set.
>>
>> Did you tried reconstructing the loop yourself and testing it? I am
>> quite curious what is your observation.
>>
>
>
>
>> cheers
>>
>>
>>
>>
>> On 8/28/06, Rainer Machne <ra...@tb...> wrote:
>>> Hi Eryk,
>>>
>>>
>>> you wrote:
>>>
>>>> the loop includes:
>>>> {
>>>> change of the parameters
>>>
>>> ... and ...
>>>
>>>> What I observe and call a problem is that every new simulator run in
>>>> the loop generates increasing sensitivity values for the same
>>>> parameter values and model.
>>>
>>
>>
>>> For the first statement `change of the parameters' it would be obvious,
>>> that sensitivities change, I guess the sensitivities can also change their
>>> sign, e.g. if during the parameter change you cross a bifurcation point.
>>>
>>> This can of course also happen for parameters that you have not changed!
>>> I.e. you change parameter A across a bifurcation point. Then the behaviour
>>> of the system completely changes. Then of course also the sensitivities to
>>> unchanged parameters change. They can even change their sign.
>>>
>>> Do you also observe the change of sensitivities if you DO NOT change the
>>> parameters between the runs?
>>>
>>> Rainer
>>>
>>>
>> Rainer, this might be obvious, but imagine
>>
>>
>>
>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Tue, 15 Aug 2006, W Eryk Wolski wrote:
>>>
>>>> Hi,
>>>>
>>>> I am running the solver in a loop.
>>>>
>>>> the loop includes:
>>>> {
>>>> change of the parameters
>>>> running the solver
>>>> and a call to IntegratorInstance_reset(integratorInstance);
>>>> }
>>>>
>>>> What I observe and call a problem is that every new simulator run in
>>>> the loop generates increasing sensitivity values for the same
>>>> parameter values and model.
>>>>
>>>> The following output are the date stored in:
>>>>
>>>> integratorInstance->data->sensitivity
>>>> entries
>>>> integratorInstance->data->nsens, integratorInstance->data->neq
>>>>
>>>> first iteration
>>>>
>>>> parameters: par[0] 2.000000 par[1] 8.000000 par[2] 10.000000
>>>> par[3] 0.100000 par[4] 2.000000
>>>>
>>>> 24.33599 -12.44311 -1.60336 0.28326 26.31235 -0.12182 0.00000 0.00000
>>>> -24.33599 12.44311 1.60336 -0.28326 -26.31235 0.12182 0.00000 11.93225
>>>> 11.93225 -4.09705 -0.54112 0.08923 8.68924 -0.04727 0.00000 -7.76276
>>>> -7.76276 2.05021 0.27103 -0.04458 -4.34843 0.02380 0.00000 -4.16949
>>>> -4.16949 2.04684 0.27009 -0.04465 -4.34081 0.02346 0.00000 -0.26712
>>>> -0.26712 -0.45221 -0.06041 0.00965 0.95925 -0.00565 0.00000 -1.57271
>>>>
>>>>
>>>> while the 10 iteration:
>>>>
>>>> -1394.82594 399.44848 59.25448 -19.98846 -2225.46440 3.11907 0.00000 0.00000
>>>> 1394.82594 -399.44848 -59.25448 19.98846 2225.46440 -3.11907 0.00000 -21877.33372
>>>> -21877.33372 6547.28853 971.83061 -324.87728 -36996.03248 52.60350 0.00000 -2206.49496
>>>> -2206.49496 666.20014 98.97768 -33.06429 -3791.30589 5.39430 0.00000 24083.82868
>>>> 24083.82868 -7213.48867 -1070.80829 357.94157 40787.33837 -57.99780 0.00000 -21953.82949
>>>> -21953.82949 6578.30322 976.54971 -326.41598 -37205.87555 52.90915 0.00000 12235.00898
>>>>
>>>>
>>>>
>>>> I hope that the problem statement is clear but I am happy to answer
>>>> more questions.
>>>> I am looking forward to suggestions.
>>>>
>>>> Eryk
>>>>
>>>> -------------------------------------------------------------------------
>>>> Using Tomcat but need to do more? Need to support web services, security?
>>>> Get stuff done quickly with pre-integrated technology to make your job easier
>>>> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>>>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>>>> _______________________________________________
>>>> sbmlsolver-devel mailing list
>>>> sbm...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>>>>
>>>
>>
>> -------------------------------------------------------------------------
>> Using Tomcat but need to do more? Need to support web services, security?
>> Get stuff done quickly with pre-integrated technology to make your job easier
>> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>> _______________________________________________
>> sbmlsolver-devel mailing list
>> sbm...@li...
>> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> sbmlsolver-devel mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>
|
