Menu
▾
▴
[SOSlib-devel] SOLVED: Problem with senstivities
|
From: Rainer M. <ra...@tb...> - 2006-08-30 13:58:36
|
Hi Eryk,
oh, how i love bugfixing :-) especially when meandering around to places
far away from a very stupid and simple bug.
When creating the sensitivity solver structures the initial sensitivities
yS where initialized after both CVodeSensMalloc or the alternative used in
subsequent loops, CVodeSensReInit. yS is passed to both functions.
While in the first case this didn't cause problems, for reinitiation CVode
overruled the initialization with its internal values upon the first call
of CVode in the _cvodeOneStep function.
During meandering around I also realized that the CVodeSens structure
requires its own free, CVodeSensFree, which was missing so far and caused
the error, when I experimentally destroyed and re-created the sens.
structures instead of ReInitializing. The missing free also is responsible
for earlier observations of significant memory leaks of the sensitivity
tools in SOSlib. These have also gone, at least during some initial test.
Eryk, can update from CVS and try your tool? I am confident that the
sensitivities now should be the same for all iterations. Here it works.
Also, if you find the time, you could report this bug to the sourceforge
bug list, as you found it. Ifit works for you, I can then close the bug
with explanations :)
cheers
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
>
|
