sbmlsolver-discuss — support and discussion for the SBML ODE Solver Library

Re: [SOSlib-discuss] Problem on simulating models with triggers andevents[Scanned]

[Rainer M. <ra...@tb...>]

Hi Eva,

Eric's hints are correct. SOSlib can handle SBML events, it is however 
not fully SBML-conformant. Here some more background:

SOSlib does NOT detect the exact time an event trigger fires. This would 
in principle be possible using CVODES' root finding capabilities - which 
however would also significantly slow down the solver. We plan to 
implement root finding first for the new SBML 'constraints', and later 
extend this to implement exact event trigger detection. However, I can't 
give a time-frame for that development.


setHaltOnEvent option:

Currently, setting the option setHaltOnEvent to 0 (-n in the 
command-line tool) activates trigger firing and execution of event 
assignments between the requested solver steps (--printstep on 
command-line, and CvodeSettings_setPrintstep(set, int i).

For many event models and purposes this is enough, but the 
user/application has to set printsteps accordingly to obtain the desired 
accuracy and to avoid missing of events. For example, SOSlib solves the 
event models in the official (but outdated) semantic-testsuite correctly 
when the appropriate printstep is chosen. Also I am not aware of any 
model in Biomodels where SOSlib event handling would cause real problems 
(but maybe Lukas can give some examples, if he's reading :) ).

The default for this option is to STOP the solver when events are 
triggered, as we can't guarantee the results. Thus the user/application 
is required to specifically activate it.


setResetCvodeOnEvent option:

When an event assignment resets variables Y of the ODE system f(Y,p,t) = 
dY/dt, then the CVODES solver must be reinitialized in any case, and 
this is always done. If the event assignment only changes the 
right-hand-side of the ODE system, it is recommended to also 
reinitialize the solver, as such discontinuities screw up CVODES' error 
estimations (as far as i understand it). Thus, it is recommended to 
activate the setResetCvodeOnEvent option, but for simple cases this is 
also not necessary - the solver is faster if not reset on such event 
assignments.
For the next release, also this option will be active on default!


new options in next release:

For the immediate next release, it is planned to introduce a simple new 
option, 'timeStepResolution', which activates internal integration steps 
between the then only external printstep. This will allow a finer 
resolution of event trigger detection without having all the values in 
the output. So e.g. in a simulation to time 1000 seconds, with printstep 
50, the event triggers are only checked every 20 seconds. You would need 
  printstep 1000 to detect at every second, but you would also get 1000 
result lines. With the new option one will be able to e.g. set 
StepResolution to 20 and Printstep to 50 to get the same result, but 
with only 50 lines of results.

If your application uses the IntegratorInstance_integrateOneStep and 
reads results between steps itself (rather then using storage of results 
with option StoreResults), you can easily implement higher detection 
resolution without overloading the output yourself.


And one more thing to note:

The new lack of (assignment) rule ordering restrictions in L2V3 would 
make it necessary to also account for correct order of rule evaluation 
in event trigger and assignment handling (see my recent email and 
responses to the sbml-discuss list). I hope, but I am not sure if I have 
time, to implement the possibility of such complex dependency trees (or 
DAGs actually) of event triggers, event assignments, and normal 
assignment rules also for the next release.

Please keep asking, if you have any more questions or suggestions on 
SOSlib's event handling.

Rainer




Eric Fernandez wrote:
> Dear Eva,
>  
> I am coming back to you. I have checked the options you need to activate 
> to enable the event evaluation during an integration. You must use:
> - cvodeSettings_setHaltOnEvent(cvodeSettings_t *set, int i) -> i=0 
> (default is 1) to continue after an event, otherwise it halts, which is 
> the default!
> - cvodeSettings_setResetCvodeOnEvent(cvodeSettings_t *set, int i) -> i=1 
> recommended, free and restart integrator after an event.
>  
> Hope this helps,
> Eric
> 
>     ------------------------------------------------------------------------
>     *From:* Eva Sciacca [mailto:sc...@mi...]
>     *Sent:* 17 October 2008 20:37
>     *To:* sbm...@li...
>     *Subject:* [SOSlib-discuss] Problem on simulating models with
>     triggers andevents[Scanned]
> 
>     Dear all,
> 
>     While I was trying to do some testing using SOSlib I had this errors
>     on running one model from BioModels DataBase.
> 
>     Warning    10001    The model contains events. The SBML_odeSolver
>     implementation of events is not fully SBML conformant.
>     Results will depend on the simulation duration and the number of
>     output steps.
>     Error    20001    Event Trigger 1 (leq(UbE, 0.1)) fired at time 16.
>     Aborting simulation.
> 
>     So, the current version 1.6.0 does not support the triggers? What
>     about the newer version? Are you going to solve this problem? When
>     it will be available???
> 
>     Eva.
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> sbmlsolver-discuss mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-discuss

Re: [SOSlib-discuss] Problem on simulating models with triggers andevents[Scanned]

[Eric F. <efe...@ph...>]

Dear Eva,
 
I am coming back to you. I have checked the options you need to activate
to enable the event evaluation during an integration. You must use:
- cvodeSettings_setHaltOnEvent(cvodeSettings_t *set, int i) -> i=0
(default is 1) to continue after an event, otherwise it halts, which is
the default!
- cvodeSettings_setResetCvodeOnEvent(cvodeSettings_t *set, int i) -> i=1
recommended, free and restart integrator after an event.
 
Hope this helps,
Eric


________________________________

	From: Eva Sciacca [mailto:sc...@mi...] 
	Sent: 17 October 2008 20:37
	To: sbm...@li...
	Subject: [SOSlib-discuss] Problem on simulating models with
triggers andevents[Scanned]
	
	
	Dear all,
	
	While I was trying to do some testing using SOSlib I had this
errors on running one model from BioModels DataBase.
	
	Warning    10001    The model contains events. The
SBML_odeSolver implementation of events is not fully SBML conformant. 
	Results will depend on the simulation duration and the number of
output steps.
	Error    20001    Event Trigger 1 (leq(UbE, 0.1)) fired at time
16. Aborting simulation.
	
	So, the current version 1.6.0 does not support the triggers?
What about the newer version? Are you going to solve this problem? When
it will be available???
	
	Eva.
	

Re: [SOSlib-discuss] Problem on simulating models with triggers andevents[Scanned]

[Eric F. <efe...@ph...>]

Hi Eva,

Actually SOSlib DOES support events, but you need to allow them in the settings (if you use the odeSolver executable, use the -n switch. You may have to use the -z option too, to prevent integration crashes with the events. Look in the API doc what these -n and -z switches correspond to in the odeSettings structure (I don't have my doc with me at the moment).
It says it is not SBML conformant because the event evaluation is not always exact, but depends on the stepping, on the integration granularity. Chose a stepping short enough not to "miss" any event trigger.

Regards,
Eric


-----Original Message-----
From: Eva Sciacca [mailto:sc...@mi...]
Sent: Fri 10/17/2008 8:36 PM
To: sbm...@li...
Subject: [SOSlib-discuss] Problem on simulating models with triggers andevents[Scanned]
 
Dear all,

While I was trying to do some testing using SOSlib I had this errors on
running one model from BioModels DataBase.

Warning    10001    The model contains events. The SBML_odeSolver
implementation of events is not fully SBML conformant.
Results will depend on the simulation duration and the number of output
steps.
Error    20001    Event Trigger 1 (leq(UbE, 0.1)) fired at time 16. Aborting
simulation.

So, the current version 1.6.0 does not support the triggers? What about the
newer version? Are you going to solve this problem? When it will be
available???

Eva.

[SOSlib-discuss] Problem on simulating models with triggers and events

[Eva S. <sc...@mi...>]

Dear all,

While I was trying to do some testing using SOSlib I had this errors on
running one model from BioModels DataBase.

Warning    10001    The model contains events. The SBML_odeSolver
implementation of events is not fully SBML conformant.
Results will depend on the simulation duration and the number of output
steps.
Error    20001    Event Trigger 1 (leq(UbE, 0.1)) fired at time 16. Aborting
simulation.

So, the current version 1.6.0 does not support the triggers? What about the
newer version? Are you going to solve this problem? When it will be
available???

Eva.

[SOSlib-discuss] new topological sorting in CVS

[Rainer M. <ra...@tb...>]

Hi,

FYI, the new topological sorting is now in CVS now.

All programs in the example folder work as before (batch_integrate.c has 
some internal bugs), including sensitivity and adjoint solver examples.

The SBML semantic test suite also works fine, including some tests which 
failed so far for the commandline compilation (related to a bug in 
piecewise expressions).

Also, I have started to document the functionality of the library at
http://www.tbi.univie.ac.at/wiki/index.php/SOSlib
which shows which sosLib functionality is supposed to work with which 
SBML feature.

next steps before release:
* implementation of the internal arithmetic compiler (whcih currently 
can be tested with 'make DEFS="-DARITHMETIC_COMPILER"').
* implement SBML constraints
* option for higher internal resolution (optionally integrate several 
steps within IntegratorInstance_integrateOneStep) for an improved 
handling of SBML events

Thanks,
Rainer

Re: [SOSlib-discuss] compiled model simulation now segfaults[Scanned]

[Rainer M. <ra...@tb...>]

Eric Fernandez wrote:
> Rainer,
> 
> I am as puzzled as you actually! I cannot get the error anymore, but I
> uninstalled the older libraries and reinstalled, might explain the
> issue.

Yeah, that works for me too.

It is the old story: the command-line compiler includes the globally 
installed sosLib header files, so it requires a `make install', so that 
really the current header files are included, and not older ones.

Maybe we can introduce some option "useLocalHeaders" for compilation, so 
the compiler command includes the local header files and lib for testing.

Rainer



> 
> Cheers,
> Eric 
> 
>> -----Original Message-----
>> From: Rainer Machne [mailto:ra...@tb...] 
>> Sent: 08 October 2008 11:59
>> To: Eric Fernandez
>> Cc: sbm...@li...
>> Subject: Re: [SOSlib-discuss] compiled model simulation now 
>> segfaults[Scanned]
>>
>> Hi Eric,
>>
>> I get the same error for the current CVS state, sorry for that!
>> So far I couldn't find out what it is. It seems that the 
>> compiled rhs. 
>> functions don't recognize cvodeData.
>>
>> However, my current state here doesn't have this problem!
>> I will commit to CVS later today or tomorrow (including all 
>> the new topological sorting stuff), and I am ... pretty 
>> confident ... that everything should work as before.
>>
>> Rainer
>>
>>
>> Eric Fernandez wrote:
>>> Hi,
>>>
>>> Some change made to SOSlib now leads odeSolver to segfaults when 
>>> trying to simulate a model with compilation, at least on my system 
>>> (AIX). Do you see that under Linux ? I don't know if it 
>> also segfaults 
>>> with other projects uding SOSlib, I only tested odeSolver/odeSolver.
>>>
>>> I double checked with an older CVS which behaves properly. Updated 
>>> files since this one are:
>>> U examples/ASTgetIndexTest.c
>>> P examples/Makefile.am
>>> P examples/Sense.c
>>> P examples/adj_sensitivity.c
>>> P examples/adjsenstest.c
>>> P examples/adjsenstest_ContDiscData.c
>>> P examples/batch_integrate.c
>>> P examples/integrate.c
>>> P examples/sensitivity.c
>>> P examples/senstest.c
>>> P examples/simpleIntegratorInstance.c
>>> cvs update: Updating odeSolver
>>> P odeSolver/printModel.c
>>> cvs update: Updating sbml
>>> cvs update: Updating scripts
>>> cvs update: Updating src
>>> P src/arithmeticCompiler.c
>>> P src/cvodeData.c
>>> P src/cvodeSolver.c
>>> P src/integratorInstance.c
>>> P src/modelSimplify.c
>>> P src/odeConstruct.c
>>> P src/odeModel.c
>>> P src/processAST.c
>>> P src/sensSolver.c
>>> P src/solverError.c
>>> cvs update: Updating src/sbmlsolver
>>> P src/sbmlsolver/cvodeData.h
>>> P src/sbmlsolver/odeModel.h
>>> P src/sbmlsolver/processAST.h
>>> P src/sbmlsolver/solverError.h
>>>
>>> I have not identified the problem yet.
>>>
>>> Regards,
>>> Eric
>>>
>>>
>> ----------------------------------------------------------------------
>>> --- This SF.Net email is sponsored by the Moblin Your Move 
>> Developer's 
>>> challenge Build the coolest Linux based applications with 
>> Moblin SDK & 
>>> win great prizes Grand prize is a trip for two to an Open 
>> Source event 
>>> anywhere in the world 
>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>> _______________________________________________
>>> sbmlsolver-discuss mailing list
>>> sbm...@li...
>>> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-discuss
>>

Re: [SOSlib-discuss] compiled model simulation now segfaults

[Rainer M. <ra...@tb...>]

Hi Eric,

I get the same error for the current CVS state, sorry for that!
So far I couldn't find out what it is. It seems that the compiled rhs. 
functions don't recognize cvodeData.

However, my current state here doesn't have this problem!
I will commit to CVS later today or tomorrow (including all the new 
topological sorting stuff), and I am ... pretty confident ... that 
everything should work as before.

Rainer


Eric Fernandez wrote:
> Hi,
> 
> Some change made to SOSlib now leads odeSolver to segfaults when trying
> to simulate a model with compilation, at least on my system (AIX). Do
> you see that under Linux ? I don't know if it also segfaults with other
> projects uding SOSlib, I only tested odeSolver/odeSolver.
> 
> I double checked with an older CVS which behaves properly. Updated files
> since this one are:
> U examples/ASTgetIndexTest.c
> P examples/Makefile.am
> P examples/Sense.c
> P examples/adj_sensitivity.c
> P examples/adjsenstest.c
> P examples/adjsenstest_ContDiscData.c
> P examples/batch_integrate.c
> P examples/integrate.c
> P examples/sensitivity.c
> P examples/senstest.c
> P examples/simpleIntegratorInstance.c
> cvs update: Updating odeSolver
> P odeSolver/printModel.c
> cvs update: Updating sbml
> cvs update: Updating scripts
> cvs update: Updating src
> P src/arithmeticCompiler.c
> P src/cvodeData.c
> P src/cvodeSolver.c
> P src/integratorInstance.c
> P src/modelSimplify.c
> P src/odeConstruct.c
> P src/odeModel.c
> P src/processAST.c
> P src/sensSolver.c
> P src/solverError.c
> cvs update: Updating src/sbmlsolver
> P src/sbmlsolver/cvodeData.h
> P src/sbmlsolver/odeModel.h
> P src/sbmlsolver/processAST.h
> P src/sbmlsolver/solverError.h
> 
> I have not identified the problem yet.
> 
> Regards,
> Eric
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> sbmlsolver-discuss mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-discuss

[SOSlib-discuss] [SOLVED?] compiled model simulation now segfaults[Scanned]

[Eric F. <efe...@ph...>]

Hi,

I answer to myself to report it now works after I did a "make install".
There may have been some libraries left from an older install. Is that
possible ? Very strange...

Eric

> -----Original Message-----
> From: Eric Fernandez [mailto:efe...@ph...] 
> Sent: 08 October 2008 11:37
> To: sbm...@li...
> Subject: [SOSlib-discuss] compiled model simulation now 
> segfaults[Scanned]
> 
> Hi,
> 
> Some change made to SOSlib now leads odeSolver to segfaults 
> when trying to simulate a model with compilation, at least on 
> my system (AIX). Do you see that under Linux ? I don't know 
> if it also segfaults with other projects uding SOSlib, I only 
> tested odeSolver/odeSolver.
> 
> I double checked with an older CVS which behaves properly. 
> Updated files since this one are:
> U examples/ASTgetIndexTest.c
> P examples/Makefile.am
> P examples/Sense.c
> P examples/adj_sensitivity.c
> P examples/adjsenstest.c
> P examples/adjsenstest_ContDiscData.c
> P examples/batch_integrate.c
> P examples/integrate.c
> P examples/sensitivity.c
> P examples/senstest.c
> P examples/simpleIntegratorInstance.c
> cvs update: Updating odeSolver
> P odeSolver/printModel.c
> cvs update: Updating sbml
> cvs update: Updating scripts
> cvs update: Updating src
> P src/arithmeticCompiler.c
> P src/cvodeData.c
> P src/cvodeSolver.c
> P src/integratorInstance.c
> P src/modelSimplify.c
> P src/odeConstruct.c
> P src/odeModel.c
> P src/processAST.c
> P src/sensSolver.c
> P src/solverError.c
> cvs update: Updating src/sbmlsolver
> P src/sbmlsolver/cvodeData.h
> P src/sbmlsolver/odeModel.h
> P src/sbmlsolver/processAST.h
> P src/sbmlsolver/solverError.h
> 
> I have not identified the problem yet.
> 
> Regards,
> Eric
> 
> --------------------------------------------------------------
> -----------
> This SF.Net email is sponsored by the Moblin Your Move 
> Developer's challenge Build the coolest Linux based 
> applications with Moblin SDK & win great prizes Grand prize 
> is a trip for two to an Open Source event anywhere in the 
> world http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> sbmlsolver-discuss mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-discuss
> 

Re: [SOSlib-discuss] compiled model simulation now segfaults[Scanned]

[Eric F. <efe...@ph...>]

Rainer,

That explains the issue then. Good to know!

Thanks a lot,
Eric 

> -----Original Message-----
> From: Rainer Machne [mailto:ra...@tb...] 
> Sent: 08 October 2008 12:04
> To: Eric Fernandez
> Cc: sbm...@li...
> Subject: Re: [SOSlib-discuss] compiled model simulation now 
> segfaults[Scanned]
> 
> Eric Fernandez wrote:
> > Rainer,
> > 
> > I am as puzzled as you actually! I cannot get the error 
> anymore, but I 
> > uninstalled the older libraries and reinstalled, might explain the 
> > issue.
> 
> Yeah, that works for me too.
> 
> It is the old story: the command-line compiler includes the 
> globally installed sosLib header files, so it requires a 
> `make install', so that really the current header files are 
> included, and not older ones.
> 
> Maybe we can introduce some option "useLocalHeaders" for 
> compilation, so the compiler command includes the local 
> header files and lib for testing.
> 
> Rainer
> 
> 
> 
> > 
> > Cheers,
> > Eric
> > 
> >> -----Original Message-----
> >> From: Rainer Machne [mailto:ra...@tb...]
> >> Sent: 08 October 2008 11:59
> >> To: Eric Fernandez
> >> Cc: sbm...@li...
> >> Subject: Re: [SOSlib-discuss] compiled model simulation now 
> >> segfaults[Scanned]
> >>
> >> Hi Eric,
> >>
> >> I get the same error for the current CVS state, sorry for that!
> >> So far I couldn't find out what it is. It seems that the compiled 
> >> rhs.
> >> functions don't recognize cvodeData.
> >>
> >> However, my current state here doesn't have this problem!
> >> I will commit to CVS later today or tomorrow (including 
> all the new 
> >> topological sorting stuff), and I am ... pretty confident ... that 
> >> everything should work as before.
> >>
> >> Rainer
> >>
> >>
> >> Eric Fernandez wrote:
> >>> Hi,
> >>>
> >>> Some change made to SOSlib now leads odeSolver to segfaults when 
> >>> trying to simulate a model with compilation, at least on 
> my system 
> >>> (AIX). Do you see that under Linux ? I don't know if it
> >> also segfaults
> >>> with other projects uding SOSlib, I only tested 
> odeSolver/odeSolver.
> >>>
> >>> I double checked with an older CVS which behaves 
> properly. Updated 
> >>> files since this one are:
> >>> U examples/ASTgetIndexTest.c
> >>> P examples/Makefile.am
> >>> P examples/Sense.c
> >>> P examples/adj_sensitivity.c
> >>> P examples/adjsenstest.c
> >>> P examples/adjsenstest_ContDiscData.c
> >>> P examples/batch_integrate.c
> >>> P examples/integrate.c
> >>> P examples/sensitivity.c
> >>> P examples/senstest.c
> >>> P examples/simpleIntegratorInstance.c
> >>> cvs update: Updating odeSolver
> >>> P odeSolver/printModel.c
> >>> cvs update: Updating sbml
> >>> cvs update: Updating scripts
> >>> cvs update: Updating src
> >>> P src/arithmeticCompiler.c
> >>> P src/cvodeData.c
> >>> P src/cvodeSolver.c
> >>> P src/integratorInstance.c
> >>> P src/modelSimplify.c
> >>> P src/odeConstruct.c
> >>> P src/odeModel.c
> >>> P src/processAST.c
> >>> P src/sensSolver.c
> >>> P src/solverError.c
> >>> cvs update: Updating src/sbmlsolver
> >>> P src/sbmlsolver/cvodeData.h
> >>> P src/sbmlsolver/odeModel.h
> >>> P src/sbmlsolver/processAST.h
> >>> P src/sbmlsolver/solverError.h
> >>>
> >>> I have not identified the problem yet.
> >>>
> >>> Regards,
> >>> Eric
> >>>
> >>>
> >> 
> ---------------------------------------------------------------------
> >> -
> >>> --- This SF.Net email is sponsored by the Moblin Your Move
> >> Developer's
> >>> challenge Build the coolest Linux based applications with
> >> Moblin SDK &
> >>> win great prizes Grand prize is a trip for two to an Open
> >> Source event
> >>> anywhere in the world
> >>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> >>> _______________________________________________
> >>> sbmlsolver-discuss mailing list
> >>> sbm...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-discuss
> >>
> 
> 

Re: [SOSlib-discuss] compiled model simulation now segfaults[Scanned]

[Eric F. <efe...@ph...>]

Rainer,

I am as puzzled as you actually! I cannot get the error anymore, but I
uninstalled the older libraries and reinstalled, might explain the
issue.

Cheers,
Eric 

> -----Original Message-----
> From: Rainer Machne [mailto:ra...@tb...] 
> Sent: 08 October 2008 11:59
> To: Eric Fernandez
> Cc: sbm...@li...
> Subject: Re: [SOSlib-discuss] compiled model simulation now 
> segfaults[Scanned]
> 
> Hi Eric,
> 
> I get the same error for the current CVS state, sorry for that!
> So far I couldn't find out what it is. It seems that the 
> compiled rhs. 
> functions don't recognize cvodeData.
> 
> However, my current state here doesn't have this problem!
> I will commit to CVS later today or tomorrow (including all 
> the new topological sorting stuff), and I am ... pretty 
> confident ... that everything should work as before.
> 
> Rainer
> 
> 
> Eric Fernandez wrote:
> > Hi,
> > 
> > Some change made to SOSlib now leads odeSolver to segfaults when 
> > trying to simulate a model with compilation, at least on my system 
> > (AIX). Do you see that under Linux ? I don't know if it 
> also segfaults 
> > with other projects uding SOSlib, I only tested odeSolver/odeSolver.
> > 
> > I double checked with an older CVS which behaves properly. Updated 
> > files since this one are:
> > U examples/ASTgetIndexTest.c
> > P examples/Makefile.am
> > P examples/Sense.c
> > P examples/adj_sensitivity.c
> > P examples/adjsenstest.c
> > P examples/adjsenstest_ContDiscData.c
> > P examples/batch_integrate.c
> > P examples/integrate.c
> > P examples/sensitivity.c
> > P examples/senstest.c
> > P examples/simpleIntegratorInstance.c
> > cvs update: Updating odeSolver
> > P odeSolver/printModel.c
> > cvs update: Updating sbml
> > cvs update: Updating scripts
> > cvs update: Updating src
> > P src/arithmeticCompiler.c
> > P src/cvodeData.c
> > P src/cvodeSolver.c
> > P src/integratorInstance.c
> > P src/modelSimplify.c
> > P src/odeConstruct.c
> > P src/odeModel.c
> > P src/processAST.c
> > P src/sensSolver.c
> > P src/solverError.c
> > cvs update: Updating src/sbmlsolver
> > P src/sbmlsolver/cvodeData.h
> > P src/sbmlsolver/odeModel.h
> > P src/sbmlsolver/processAST.h
> > P src/sbmlsolver/solverError.h
> > 
> > I have not identified the problem yet.
> > 
> > Regards,
> > Eric
> > 
> > 
> ----------------------------------------------------------------------
> > --- This SF.Net email is sponsored by the Moblin Your Move 
> Developer's 
> > challenge Build the coolest Linux based applications with 
> Moblin SDK & 
> > win great prizes Grand prize is a trip for two to an Open 
> Source event 
> > anywhere in the world 
> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > _______________________________________________
> > sbmlsolver-discuss mailing list
> > sbm...@li...
> > https://lists.sourceforge.net/lists/listinfo/sbmlsolver-discuss
> 
> 

[SOSlib-discuss] compiled model simulation now segfaults

[Eric F. <efe...@ph...>]

Hi,

Some change made to SOSlib now leads odeSolver to segfaults when trying
to simulate a model with compilation, at least on my system (AIX). Do
you see that under Linux ? I don't know if it also segfaults with other
projects uding SOSlib, I only tested odeSolver/odeSolver.

I double checked with an older CVS which behaves properly. Updated files
since this one are:
U examples/ASTgetIndexTest.c
P examples/Makefile.am
P examples/Sense.c
P examples/adj_sensitivity.c
P examples/adjsenstest.c
P examples/adjsenstest_ContDiscData.c
P examples/batch_integrate.c
P examples/integrate.c
P examples/sensitivity.c
P examples/senstest.c
P examples/simpleIntegratorInstance.c
cvs update: Updating odeSolver
P odeSolver/printModel.c
cvs update: Updating sbml
cvs update: Updating scripts
cvs update: Updating src
P src/arithmeticCompiler.c
P src/cvodeData.c
P src/cvodeSolver.c
P src/integratorInstance.c
P src/modelSimplify.c
P src/odeConstruct.c
P src/odeModel.c
P src/processAST.c
P src/sensSolver.c
P src/solverError.c
cvs update: Updating src/sbmlsolver
P src/sbmlsolver/cvodeData.h
P src/sbmlsolver/odeModel.h
P src/sbmlsolver/processAST.h
P src/sbmlsolver/solverError.h

I have not identified the problem yet.

Regards,
Eric

[SOSlib-discuss] events (was Re: ODEModel_createWithObservables)

[Rainer M. <ra...@tb...>]

Eric Fernandez wrote:
> Hi,
> 
> That seems fine for me. However would that affect event evaluation ?

No, it behaves exactly the same as before: only those rules are 
evaluated that are required for event evaluation. Additional rules are 
only evaluated if the assigned value is specifically requested.

However, we identified one problem for the current event implementation, 
or more general the current handling of setting new parameter values 
during integration.

We previously assumed that CVODES doesn't care about discontinuities in 
the right-hand-side functions of the ODE model, and only discontinuities 
in the left-hand-side, i.e. resetting of ODE variables, would require 
re-initialization of the solver.
Unfortunately, that is not entirely true.

While for most cases it doesn't cause big problems, in general their 
should be no discontinuities also in the r.h.s. Especially the requested 
error tolerances won't be correct.

That means that we might need to reinitialize the CVODES solver 
structures for ALL EVENTS, not only those which reset ODE variables!


Maybe, we can introduce an option, or use the existing option 
"opt->ResetCvodeOnEvent" (of which I suspect Andrew introduced it only 
for testing purposes) to test the two cases, and how it affects 
performance if we only reset the solver for new ODE variables (l.h.s 
discont. as currently) OR for all new parameters (r.h.s discont.).

Rainer




> 
> Eric
> 
>> -----Original Message-----
>> From: Rainer Machne [mailto:ra...@tb...] 
>> Sent: 06 October 2008 14:38
>> To: sbm...@li...
>> Subject: Re: [SOSlib-discuss] ODEModel_createWithObservables[Scanned]
>>
>> Hi,
>>
>> I think we can get rid of the "observables" all together. I 
>> have moved update of all assignment rules - even those which 
>> are not required to solve the system - to the two cases were required:
>>
>> a) with option StoreResults: all values are stored, so all 
>> rules need to be updated anyways
>>
>> b) IntegratorInstance_getVariableValue: if an assigned value 
>> is requested specifically, then assignment rules are updated 
>> (but only once, if the function is used several times at the 
>> same integration step!).
>>
>> So if you solve without the StoreResults option, and don't 
>> use getVariableValue for assigned values (rate laws, values 
>> only in the model for observation purposes), the solver will 
>> always only update the required rules.
>>
>> At a later point also the complete rule evaluation for above 
>> cases could be optimized by storing the dependency graph 
>> between assignments and use a recursive evaluation through 
>> this graph ONLY for the requested values.
>>
>> As a conclusion, "observables" to optimize solver performance 
>> is not required anymore, and I will remove this functionality 
>> completely.
>>
>> Any objections?
>>
>> Rainer

Re: [SOSlib-discuss] ODEModel_createWithObservables[Scanned]

[Eric F. <efe...@ph...>]

Hi,

That seems fine for me. However would that affect event evaluation ?

Eric

> -----Original Message-----
> From: Rainer Machne [mailto:ra...@tb...] 
> Sent: 06 October 2008 14:38
> To: sbm...@li...
> Subject: Re: [SOSlib-discuss] ODEModel_createWithObservables[Scanned]
> 
> Hi,
> 
> I think we can get rid of the "observables" all together. I 
> have moved update of all assignment rules - even those which 
> are not required to solve the system - to the two cases were required:
> 
> a) with option StoreResults: all values are stored, so all 
> rules need to be updated anyways
> 
> b) IntegratorInstance_getVariableValue: if an assigned value 
> is requested specifically, then assignment rules are updated 
> (but only once, if the function is used several times at the 
> same integration step!).
> 
> So if you solve without the StoreResults option, and don't 
> use getVariableValue for assigned values (rate laws, values 
> only in the model for observation purposes), the solver will 
> always only update the required rules.
> 
> At a later point also the complete rule evaluation for above 
> cases could be optimized by storing the dependency graph 
> between assignments and use a recursive evaluation through 
> this graph ONLY for the requested values.
> 
> As a conclusion, "observables" to optimize solver performance 
> is not required anymore, and I will remove this functionality 
> completely.
> 
> Any objections?
> 
> Rainer

Re: [SOSlib-discuss] ODEModel_createWithObservables

[Rainer M. <ra...@tb...>]

Hi,

I think we can get rid of the "observables" all together. I have moved 
update of all assignment rules - even those which are not required to 
solve the system - to the two cases were required:

a) with option StoreResults: all values are stored, so all rules need to 
be updated anyways

b) IntegratorInstance_getVariableValue: if an assigned value is 
requested specifically, then assignment rules are updated (but only 
once, if the function is used several times at the same integration step!).

So if you solve without the StoreResults option, and don't use 
getVariableValue for assigned values (rate laws, values only in the 
model for observation purposes), the solver will always only update the 
required rules.

At a later point also the complete rule evaluation for above cases could 
be optimized by storing the dependency graph between assignments and use 
a recursive evaluation through this graph ONLY for the requested values.

As a conclusion, "observables" to optimize solver performance is not 
required anymore, and I will remove this functionality completely.

Any objections?

Rainer




Rainer Machne wrote:
> Hi,
> 
> Is anyone using the functions to create an ODEModel "WithObservables"?
> 
> I plan to move this to CvodeSettings_setObservables (and to move the 
> respective structures and functions to CvodeData).
> 
> The reason is, that odeModel otherwise only depends on the SBML input, and 
> defining "observables" fits more natural to the input settings.
> Also, one odeModel can then be run with different observables sets, and 
> observables don't depend on the odeModel anymore.
> 
> fyi, the rule-ordering, which made observables necessary, is currently 
> being replaced with a topological sorting-based ordering (to allow SBML 
> L2V2 initial assignments, and lost constraints on rule ordering).
> 
> Is that a problem for anyone?
> 
> Thanks,
> Rainer
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> sbmlsolver-discuss mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-discuss

Re: [SOSlib-discuss] encapsulating an integratorInstance leads tointegration segfault[Scanned]

[Eric F. <efe...@ph...>]

Hi,

I have found the cause of the problem I reported initially, and I am
ashamed: it was a simple programming error from me. I redeclared the
cvodeSettings_t* variable in the constructor, therefore in other
functions, it was out of scope and the settings pointer of the class was
still null... This happens when working late :)

Regards,
Eric

Re: [SOSlib-discuss] ODEModel_createWithObservables[Scanned]

[Eric F. <efe...@ph...>]

Hi,

No objection from me, that sounds good.

Eric 

> -----Original Message-----
> From: Rainer Machne [mailto:ra...@tb...] 
> Sent: 03 October 2008 09:33
> To: sbm...@li...
> Subject: [SOSlib-discuss] ODEModel_createWithObservables[Scanned]
> 
> Hi,
> 
> Is anyone using the functions to create an ODEModel "WithObservables"?
> 
> I plan to move this to CvodeSettings_setObservables (and to 
> move the respective structures and functions to CvodeData).
> 
> The reason is, that odeModel otherwise only depends on the 
> SBML input, and defining "observables" fits more natural to 
> the input settings.
> Also, one odeModel can then be run with different observables 
> sets, and observables don't depend on the odeModel anymore.
> 
> fyi, the rule-ordering, which made observables necessary, is 
> currently being replaced with a topological sorting-based 
> ordering (to allow SBML
> L2V2 initial assignments, and lost constraints on rule ordering).
> 
> Is that a problem for anyone?
> 
> Thanks,
> Rainer
> 
> --------------------------------------------------------------
> -----------
> This SF.Net email is sponsored by the Moblin Your Move 
> Developer's challenge Build the coolest Linux based 
> applications with Moblin SDK & win great prizes Grand prize 
> is a trip for two to an Open Source event anywhere in the 
> world http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> sbmlsolver-discuss mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-discuss
> 

[SOSlib-discuss] ODEModel_createWithObservables

[Rainer M. <ra...@tb...>]

Hi,

Is anyone using the functions to create an ODEModel "WithObservables"?

I plan to move this to CvodeSettings_setObservables (and to move the 
respective structures and functions to CvodeData).

The reason is, that odeModel otherwise only depends on the SBML input, and 
defining "observables" fits more natural to the input settings.
Also, one odeModel can then be run with different observables sets, and 
observables don't depend on the odeModel anymore.

fyi, the rule-ordering, which made observables necessary, is currently 
being replaced with a topological sorting-based ordering (to allow SBML 
L2V2 initial assignments, and lost constraints on rule ordering).

Is that a problem for anyone?

Thanks,
Rainer

Re: [SOSlib-discuss] encapsulating an integratorInstance leads to integration segfault[Scanned]

[Eric F. <efe...@ph...>]

Hi,

Thanks for the answer, I'll work on an example very soon and will post
it.

Eric

> -----Original Message-----
> From: Rainer Machne [mailto:ra...@tb...] 
> Sent: 29 September 2008 11:00
> To: Eric Fernandez
> Cc: sbm...@li...
> Subject: Re: [SOSlib-discuss] encapsulating an 
> integratorInstance leads to integration segfault[Scanned]
> 
> Hi Eric,
> 
> We also couldn't come up with any ideas here, unfortunately. 
> Maybe, could you supply us with a full example .cpp file 
> which reproduces the problem for testing?
> 
> The only thing I could find is this:
> 
>  >   cout << "DNA: " << IntegratorInstance_getVariableValue(engine,
>  > 	
>  > ODEModel_getVariableIndex(odeModel, "dna")) << endl; // OK
> 
> ODEModel_getVariableIndex allocates memory for the 
> variableIndex_t structure. This must be freed again!
> 
> So it should be:
> 
> variableIndex_t *vi =  ODEModel_getVariableIndex(odeModel, 
> "dna"); IntegratorInstance_getVariableValue(engine, vi); 
> VariableIndex_free(vi);
> 
> But I doubt that this would cause such severe problems.
> 
> As said, a working example file or some debug information 
> would be helpful.
> 
> Rainer
> 
> 
> Eric Fernandez wrote:
> > Hi,
> > 
> > I want to encapsulate the odeSolver data structures and 
> > integratorInstance in a C++ class but integration segfaults in some 
> > conditions.
> > 
> > class Engine
> > {
> >  private:
> >   odeModel_t* odeModel;
> >   cvodeSettings_t* settings;
> >   integratorInstance_t* engine;
> >   double simTime;
> > 
> >  public:
> >   Engine(odeModel_t*, double);
> >   ~Engine();
> >   void integrateSimple();
> > };
> > 
> > ---> in the constructor I build the integratorInstance and try to
> > integrate one step:
> > 
> > Engine::Engine(odeModel_t* om, double time) : odeModel(om),
> > simTime(time)
> > {
> >   cout << "Engine Constr" << endl;
> >   
> >   // Create the settings and the integrator instance
> >   cvodeSettings_t* settings = CvodeSettings_createWith(simTime,
> > 						       simTime *
> > PSFACTOR,
> > 						       ABS_ERR,
> > 						       REL_ERR,
> > 						       10000,
> > 						       0,
> > 						       0,
> > 						       1,
> > 						       0,
> > 						       0,
> > 						       0,
> > 						       1,
> > 						       0,
> > 						       2);
> >   CvodeSettings_setCompileFunctions(settings, 1);
> >   CvodeSettings_setSteadyStateThreshold(settings, 1e-11);
> >   CvodeSettings_setResetCvodeOnEvent(settings, 1);
> >   integratorInstance_t* engine = IntegratorInstance_create(om, 
> > settings);
> > 
> >   IntegratorInstance_integrateOneStep(engine); //// TESTING
> >   cout << IntegratorInstance_getTime(engine) << endl;
> >   }
> > 
> > ----> this works: my constructor creates the engine object and
> > integrates one step succesfully.
> > 
> > ----> However, if my constructor calls :
> > 
> > Engine::Engine(odeModel_t* om, double time) : odeModel(om),
> > simTime(time)
> > {
> >   cout << "Engine Constr" << endl;
> >   
> >   // Create the settings and the integrator instance
> >   cvodeSettings_t* settings = CvodeSettings_createWith(simTime,
> > 						       simTime *
> > PSFACTOR,
> > 						       ABS_ERR,
> > 						       REL_ERR,
> > 						       10000,
> > 						       0,
> > 						       0,
> > 						       1,
> > 						       0,
> > 						       0,
> > 						       0,
> > 						       1,
> > 						       0,
> > 						       2);
> >   CvodeSettings_setCompileFunctions(settings, 1);
> >   CvodeSettings_setSteadyStateThreshold(settings, 1e-11);
> >   CvodeSettings_setResetCvodeOnEvent(settings, 1);
> >   integratorInstance_t* engine = IntegratorInstance_create(om, 
> > settings);
> > 
> >   integrateSimple();
> >   
> > }
> > 
> > void Engine::integrateSimple()
> > {
> >   cout << IntegratorInstance_getTime(engine) << endl;   //OK
> > 
> >   cout << "DNA: " << IntegratorInstance_getVariableValue(engine,
> > 	
> > ODEModel_getVariableIndex(odeModel, "dna")) << endl; // OK
> > 
> >   IntegratorInstance_integrateOneStep(engine);  // SEGFAULTS!!
> > }
> > 
> > 
> > This crash also occurs if, of course, I create an Engine 
> instance in 
> > another class or main and try to call integrateSimple() 
> independently 
> > from the constructor. This call inside the constructor was just for 
> > testing purpose.
> > 
> > Am I doing something wrong there ? There must be something 
> obvious I 
> > overlooked there but cannot find it.
> > 
> > Eric
> > 
> > 
> ----------------------------------------------------------------------
> > --- This SF.Net email is sponsored by the Moblin Your Move 
> Developer's 
> > challenge Build the coolest Linux based applications with 
> Moblin SDK & 
> > win great prizes Grand prize is a trip for two to an Open 
> Source event 
> > anywhere in the world 
> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > _______________________________________________
> > sbmlsolver-discuss mailing list
> > sbm...@li...
> > https://lists.sourceforge.net/lists/listinfo/sbmlsolver-discuss
> 
> 

Re: [SOSlib-discuss] encapsulating an integratorInstance leads to integration segfault

[Rainer M. <ra...@tb...>]

Hi Eric,

We also couldn't come up with any ideas here, unfortunately. Maybe, 
could you supply us with a full example .cpp file which reproduces the 
problem for testing?

The only thing I could find is this:

 >   cout << "DNA: " << IntegratorInstance_getVariableValue(engine,
 > 	
 > ODEModel_getVariableIndex(odeModel, "dna")) << endl; // OK

ODEModel_getVariableIndex allocates memory for the variableIndex_t 
structure. This must be freed again!

So it should be:

variableIndex_t *vi =  ODEModel_getVariableIndex(odeModel, "dna");
IntegratorInstance_getVariableValue(engine, vi);
VariableIndex_free(vi);

But I doubt that this would cause such severe problems.

As said, a working example file or some debug information would be helpful.

Rainer


Eric Fernandez wrote:
> Hi,
> 
> I want to encapsulate the odeSolver data structures and
> integratorInstance in a C++ class but integration segfaults in some
> conditions.
> 
> class Engine
> {
>  private:
>   odeModel_t* odeModel;
>   cvodeSettings_t* settings;
>   integratorInstance_t* engine;
>   double simTime;
> 
>  public:
>   Engine(odeModel_t*, double);
>   ~Engine();
>   void integrateSimple();
> };
> 
> ---> in the constructor I build the integratorInstance and try to
> integrate one step:
> 
> Engine::Engine(odeModel_t* om, double time) : odeModel(om),
> simTime(time)
> {
>   cout << "Engine Constr" << endl;
>   
>   // Create the settings and the integrator instance
>   cvodeSettings_t* settings = CvodeSettings_createWith(simTime,
> 						       simTime *
> PSFACTOR,
> 						       ABS_ERR,
> 						       REL_ERR,
> 						       10000,
> 						       0,
> 						       0,
> 						       1,
> 						       0,
> 						       0,
> 						       0,
> 						       1,
> 						       0,
> 						       2);
>   CvodeSettings_setCompileFunctions(settings, 1);
>   CvodeSettings_setSteadyStateThreshold(settings, 1e-11);
>   CvodeSettings_setResetCvodeOnEvent(settings, 1);
>   integratorInstance_t* engine = IntegratorInstance_create(om,
> settings);
> 
>   IntegratorInstance_integrateOneStep(engine); //// TESTING
>   cout << IntegratorInstance_getTime(engine) << endl;
>   }
> 
> ----> this works: my constructor creates the engine object and
> integrates one step succesfully.
> 
> ----> However, if my constructor calls :
> 
> Engine::Engine(odeModel_t* om, double time) : odeModel(om),
> simTime(time)
> {
>   cout << "Engine Constr" << endl;
>   
>   // Create the settings and the integrator instance
>   cvodeSettings_t* settings = CvodeSettings_createWith(simTime,
> 						       simTime *
> PSFACTOR,
> 						       ABS_ERR,
> 						       REL_ERR,
> 						       10000,
> 						       0,
> 						       0,
> 						       1,
> 						       0,
> 						       0,
> 						       0,
> 						       1,
> 						       0,
> 						       2);
>   CvodeSettings_setCompileFunctions(settings, 1);
>   CvodeSettings_setSteadyStateThreshold(settings, 1e-11);
>   CvodeSettings_setResetCvodeOnEvent(settings, 1);
>   integratorInstance_t* engine = IntegratorInstance_create(om,
> settings);
> 
>   integrateSimple();
>   
> }
> 
> void Engine::integrateSimple()
> {
>   cout << IntegratorInstance_getTime(engine) << endl;   //OK
> 
>   cout << "DNA: " << IntegratorInstance_getVariableValue(engine,
> 	
> ODEModel_getVariableIndex(odeModel, "dna")) << endl; // OK
> 
>   IntegratorInstance_integrateOneStep(engine);  // SEGFAULTS!!
> }
> 
> 
> This crash also occurs if, of course, I create an Engine instance in
> another class or main and try to call integrateSimple() independently
> from the constructor. This call inside the constructor was just for
> testing purpose.
> 
> Am I doing something wrong there ? There must be something obvious I
> overlooked there but cannot find it.
> 
> Eric
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> sbmlsolver-discuss mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-discuss

Re: [SOSlib-discuss] Is SOSLib Thread-Safe?

[Rainer M. <ra...@tb...>]

Hi Eva,

I am sorry for the late response. We wanted to discuss the topic a bit 
more before replying but had little time last week. Unfortunately, as 
said, we have almost no experience with bindings to SOSlib.

There are three things we could think of, but from your description it 
doesn't sound like they are the problem.

Anyways, here they are:

1) create/free ordering

integratorInstance_t depends on odeModel_t. While you can (in principle) 
create as many integratorInstances from it as you like, they all depend 
on the odeModel, ie. the odeModel (and cvodeSettings!) MUST NOT be freed 
BEFORE the integratorInstance. Both, odeModel and integratorInstance 
also require the SBML input file to exist throughout their "life cycle".

So the order must always be:
m = SBMLDocument_getModel(d);
om = ODEModel_create(m);
set = CvodeSettings_create();
intg = IntegratorInstance_create(om, set);

.... integrate ... create more integratorInstances ...

IntegratorInstance_free(intg);
... free other integratorInstances
ODEModel_free(om);
CvodeSettings_free(set);
SBMLDocument_free(d);

(Should we change that and always create internal copies of odeModel and 
cvodeSettings?)


2) Sensitivities

Eva Sciacca wrote:
> example of the corrupted results:
> 1.0054618704398094E-307 1.0095946694681969E-307 0.019900437649468944

Are these sensitivities? We know that version 1.6.0 handled CVODES 
sensitivities wrongly for iterative sensitivity calculations. This is 
however independent of parallel integratorInstances. So for two 
integratorInstances both should give correct sensitivities for their 
first run, and wrong sensitivities for the second run.

I fear, that didn't help :(

It would be great to get some additional info. Is it possible to run a 
debugger (like gdb) or memory checking tool (like valgrind) in your 
framework, which could point to specific lines of SOSlib code or 
structures that might be corrupted?


Rainer




> 
> I hope you have some other ideas or suggestions on how to solve the problem.
> 
> Eva.
> 
> On Fri, Sep 19, 2008 at 4:13 AM, Rainer Machne <ra...@tb...> wrote:
>> Hi Eva,
>>
>> We have ourself not used Java bindings. Can you give some more details which structures/functions you are using, that might cause the problem?
>> Which version are you using (there is only 1.6 and CVS :) - if CVS which date approx.)?
>>
>> In principle SOSlib is intended to be thread-safe! odeModel_t and integratorInstance_t (and all other) structures can be created, used and free'd independently, and should not cause any memory leaks or corruptions. From one SBML model many independent odeModel structures, and from each odeModel many independent integratorInstance structures can be created (and integrated in parallel). We are not aware of any current problems with that.
>>
>> Here some suggestions of past problems:
>>
>> I am not aware of of any memory problems in the 1.6 release either.
>> However, an old CVS version used TCC-based compilation and wasn't thread-safe because unfortunately TCC (as a library) is not thread-safe - we removed TCC compilation for that reason, and currently use gcc command-line calls or - very new - our own internal compiler.
>>
>> Also, some recent libSBML versions had memory problems with ASTNode structure, not freeing all parts of the abstract syntax tree correctly. It could be related to this. I am currently using libSBML CVS and haven't tested their latest official release, yet. Which libSBML version are you using?
>>
>>
>> Btw, we are currently working on a new release, which should come in the next few weeks. The code has been significantly enhanced since 1.6 and we'd be happy to support with transition to the new code. For us it would be great to get feedback already for the current CVS version before making the official release :) However, I will commit a major change today (increasing speed for large models significantly), so you might want to wait a bit.
>>
>> Thanks,
>> Rainer
>>
>> On Thu, 18 Sep 2008, Eva Sciacca wrote:
>>
>>> Dear all,
>>>
>>> we built a jni interface to use SOSLib from Java. We also compiled it as a
>>> dynamic library to be used from the Java objects. Now we are experiencing
>>> some problems on accessing the library simultaneusly creating multiple
>>> instances of Java Objects using it. It seems that, when a new object is
>>> created, the memory allocated for the library gets corrupted.
>>>
>>> Do you know if SOSLib is Thread-Safe? Do you have had any similar problems?
>>> Could you give me some advice on this problem?
>>>
>>> Thank you in advance.
>>>
>>> Eva.
>>>
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> sbmlsolver-discuss mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-discuss

[SOSlib-discuss] Is SOSLib Thread-Safe?

[Eva S. <sc...@mi...>]

Dear Rainer,

we used JNI to bind SOSlib to the Java Code. We used the following functions:

JNIEXPORT jint JNICALL Java_sbmlSolver_SBMLSolver_initSolver (JNIEnv
*, jobject, jstring, jdouble, jint);
-> create a new ODEModel and a new IntegratorInstance.
JNIEXPORT jdoubleArray JNICALL Java_sbmlSolver_SBMLSolver_runSolver
(JNIEnv *, jobject);
-> call the method IntegratorInstance_integrateOneStep for the total time steps
JNIEXPORT void JNICALL Java_sbmlSolver_SBMLSolver_destroySolver
(JNIEnv *, jobject);
-> clean up the objects.

And we called them from the Java methods:

private native int initSolver(String sbml_filename, double totalTime,
int numSteps);
private native double[] runSolver();
private native void destroySolver();

We are using SOSlib version 1.6, libsbml version 2.3.4 and xerces-c
version 2.7.0. We compiled the library SOSlib using Microsoft Visual
C++ 2005 Express Edition.

When from the Java we call initSolver for only one object everything
works just fine. But if we call initSolver to create a second object
the results are corrupted.

example of the correcty results running one time step:
661.8319461376393 81.8319461376392 18.168053862360786

example of the corrupted results:
1.0054618704398094E-307 1.0095946694681969E-307 0.019900437649468944

I hope you have some other ideas or suggestions on how to solve the problem.

Eva.

On Fri, Sep 19, 2008 at 4:13 AM, Rainer Machne <ra...@tb...> wrote:
>
> Hi Eva,
>
> We have ourself not used Java bindings. Can you give some more details which structures/functions you are using, that might cause the problem?
> Which version are you using (there is only 1.6 and CVS :) - if CVS which date approx.)?
>
> In principle SOSlib is intended to be thread-safe! odeModel_t and integratorInstance_t (and all other) structures can be created, used and free'd independently, and should not cause any memory leaks or corruptions. From one SBML model many independent odeModel structures, and from each odeModel many independent integratorInstance structures can be created (and integrated in parallel). We are not aware of any current problems with that.
>
> Here some suggestions of past problems:
>
> I am not aware of of any memory problems in the 1.6 release either.
> However, an old CVS version used TCC-based compilation and wasn't thread-safe because unfortunately TCC (as a library) is not thread-safe - we removed TCC compilation for that reason, and currently use gcc command-line calls or - very new - our own internal compiler.
>
> Also, some recent libSBML versions had memory problems with ASTNode structure, not freeing all parts of the abstract syntax tree correctly. It could be related to this. I am currently using libSBML CVS and haven't tested their latest official release, yet. Which libSBML version are you using?
>
>
> Btw, we are currently working on a new release, which should come in the next few weeks. The code has been significantly enhanced since 1.6 and we'd be happy to support with transition to the new code. For us it would be great to get feedback already for the current CVS version before making the official release :) However, I will commit a major change today (increasing speed for large models significantly), so you might want to wait a bit.
>
> Thanks,
> Rainer
>
> On Thu, 18 Sep 2008, Eva Sciacca wrote:
>
>> Dear all,
>>
>> we built a jni interface to use SOSLib from Java. We also compiled it as a
>> dynamic library to be used from the Java objects. Now we are experiencing
>> some problems on accessing the library simultaneusly creating multiple
>> instances of Java Objects using it. It seems that, when a new object is
>> created, the memory allocated for the library gets corrupted.
>>
>> Do you know if SOSLib is Thread-Safe? Do you have had any similar problems?
>> Could you give me some advice on this problem?
>>
>> Thank you in advance.
>>
>> Eva.
>>

Re: [SOSlib-discuss] Is SOSLib Thread-Safe?[Scanned]

[Eric F. <efe...@ph...>]

Hi,

I wonder if this has to do with the problem I reported yesterday with
encapsulation of integratorInstance in C++ objects. If an
integratorInstance (and settings) is created in the constructor, then
the integrateOneStep() segfaults if it is done in a member function. I
have to create the integrator, integrate and then free the integrator
within the member function to make it work, leading to code redundancy.

Eric

> -----Original Message-----
> From: sbm...@li... 
> [mailto:sbm...@li...] On 
> Behalf Of Rainer Machne
> Sent: 19 September 2008 09:14
> To: Eva Sciacca
> Cc: sbm...@li...
> Subject: Re: [SOSlib-discuss] Is SOSLib Thread-Safe?[Scanned]
> 
> Hi Eva,
> 
> We have ourself not used Java bindings. Can you give some 
> more details which structures/functions you are using, that 
> might cause the problem?
> Which version are you using (there is only 1.6 and CVS :) - 
> if CVS which date approx.)?
> 
> In principle SOSlib is intended to be thread-safe! odeModel_t 
> and integratorInstance_t (and all other) structures can be 
> created, used and free'd independently, and should not cause 
> any memory leaks or corruptions. From one SBML model many 
> independent odeModel structures, and from each odeModel many 
> independent integratorInstance structures can be created (and 
> integrated in parallel). We are not aware of any current 
> problems with that.
> 
> Here some suggestions of past problems:
> 
> I am not aware of of any memory problems in the 1.6 release either.
> However, an old CVS version used TCC-based compilation and 
> wasn't thread-safe because unfortunately TCC (as a library) 
> is not thread-safe - we removed TCC compilation for that 
> reason, and currently use gcc command-line calls or - very 
> new - our own internal compiler.
> 
> Also, some recent libSBML versions had memory problems with 
> ASTNode structure, not freeing all parts of the abstract 
> syntax tree correctly. It could be related to this. I am 
> currently using libSBML CVS and haven't tested their latest 
> official release, yet. Which libSBML version are you using?
> 
> 
> Btw, we are currently working on a new release, which should 
> come in the next few weeks. The code has been significantly 
> enhanced since 1.6 and we'd be happy to support with 
> transition to the new code. For us it would be great to get 
> feedback already for the current CVS version before making 
> the official release :) However, I will commit a major change 
> today (increasing speed for large models significantly), so 
> you might want to wait a bit.
> 
> Thanks,
> Rainer

Re: [SOSlib-discuss] Is SOSLib Thread-Safe?

[Rainer M. <ra...@tb...>]

Hi Eva,

We have ourself not used Java bindings. Can you give some more details 
which structures/functions you are using, that might cause the problem?
Which version are you using (there is only 1.6 and CVS :) - if CVS which 
date approx.)?

In principle SOSlib is intended to be thread-safe! odeModel_t and 
integratorInstance_t (and all other) structures can be created, used and 
free'd independently, and should not cause any memory leaks or 
corruptions. From one SBML model many independent odeModel structures, and 
from each odeModel many independent integratorInstance structures can be 
created (and integrated in parallel). We are not aware of any current 
problems with that.

Here some suggestions of past problems:

I am not aware of of any memory problems in the 1.6 release either.
However, an old CVS version used TCC-based compilation 
and wasn't thread-safe because unfortunately TCC (as a library) is not 
thread-safe - we removed TCC compilation for that reason, and currently 
use gcc command-line calls or - very new - our own internal compiler.

Also, some recent libSBML versions had memory problems with ASTNode 
structure, not freeing all parts of the abstract syntax tree correctly. It 
could be related to this. I am currently using libSBML CVS and haven't 
tested their latest official release, yet. Which libSBML version are you 
using?


Btw, we are currently working on a new release, which should come in the 
next few weeks. The code has been significantly enhanced since 1.6 and 
we'd be happy to support with transition to the new code. For us it would 
be great to get feedback already for the current CVS version before 
making the official release :) However, I will commit a major change 
today (increasing speed for large models significantly), so you 
might want to wait a bit.

Thanks,
Rainer

On Thu, 18 Sep 2008, Eva Sciacca wrote:

> Dear all,
>
> we built a jni interface to use SOSLib from Java. We also compiled it as a
> dynamic library to be used from the Java objects. Now we are experiencing
> some problems on accessing the library simultaneusly creating multiple
> instances of Java Objects using it. It seems that, when a new object is
> created, the memory allocated for the library gets corrupted.
>
> Do you know if SOSLib is Thread-Safe? Do you have had any similar problems?
> Could you give me some advice on this problem?
>
> Thank you in advance.
>
> Eva.
>

[SOSlib-discuss] Is SOSLib Thread-Safe?

[Eva S. <sc...@mi...>]

Dear all,

we built a jni interface to use SOSLib from Java. We also compiled it as a
dynamic library to be used from the Java objects. Now we are experiencing
some problems on accessing the library simultaneusly creating multiple
instances of Java Objects using it. It seems that, when a new object is
created, the memory allocated for the library gets corrupted.

Do you know if SOSLib is Thread-Safe? Do you have had any similar problems?
Could you give me some advice on this problem?

Thank you in advance.

Eva.

[SOSlib-discuss] encapsulating an integratorInstance leads to integration segfault

[Eric F. <efe...@ph...>]

Hi,

I want to encapsulate the odeSolver data structures and
integratorInstance in a C++ class but integration segfaults in some
conditions.

class Engine
{
 private:
  odeModel_t* odeModel;
  cvodeSettings_t* settings;
  integratorInstance_t* engine;
  double simTime;

 public:
  Engine(odeModel_t*, double);
  ~Engine();
  void integrateSimple();
};

---> in the constructor I build the integratorInstance and try to
integrate one step:

Engine::Engine(odeModel_t* om, double time) : odeModel(om),
simTime(time)
{
  cout << "Engine Constr" << endl;
  
  // Create the settings and the integrator instance
  cvodeSettings_t* settings = CvodeSettings_createWith(simTime,
						       simTime *
PSFACTOR,
						       ABS_ERR,
						       REL_ERR,
						       10000,
						       0,
						       0,
						       1,
						       0,
						       0,
						       0,
						       1,
						       0,
						       2);
  CvodeSettings_setCompileFunctions(settings, 1);
  CvodeSettings_setSteadyStateThreshold(settings, 1e-11);
  CvodeSettings_setResetCvodeOnEvent(settings, 1);
  integratorInstance_t* engine = IntegratorInstance_create(om,
settings);

  IntegratorInstance_integrateOneStep(engine); //// TESTING
  cout << IntegratorInstance_getTime(engine) << endl;
  }

----> this works: my constructor creates the engine object and
integrates one step succesfully.

----> However, if my constructor calls :

Engine::Engine(odeModel_t* om, double time) : odeModel(om),
simTime(time)
{
  cout << "Engine Constr" << endl;
  
  // Create the settings and the integrator instance
  cvodeSettings_t* settings = CvodeSettings_createWith(simTime,
						       simTime *
PSFACTOR,
						       ABS_ERR,
						       REL_ERR,
						       10000,
						       0,
						       0,
						       1,
						       0,
						       0,
						       0,
						       1,
						       0,
						       2);
  CvodeSettings_setCompileFunctions(settings, 1);
  CvodeSettings_setSteadyStateThreshold(settings, 1e-11);
  CvodeSettings_setResetCvodeOnEvent(settings, 1);
  integratorInstance_t* engine = IntegratorInstance_create(om,
settings);

  integrateSimple();
  
}

void Engine::integrateSimple()
{
  cout << IntegratorInstance_getTime(engine) << endl;   //OK

  cout << "DNA: " << IntegratorInstance_getVariableValue(engine,
	
ODEModel_getVariableIndex(odeModel, "dna")) << endl; // OK

  IntegratorInstance_integrateOneStep(engine);  // SEGFAULTS!!
}


This crash also occurs if, of course, I create an Engine instance in
another class or main and try to call integrateSimple() independently
from the constructor. This call inside the constructor was just for
testing purpose.

Am I doing something wrong there ? There must be something obvious I
overlooked there but cannot find it.

Eric