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

[SOSlib-discuss] memory exhaustion creating odeModels

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

 

> -----Original Message-----
> From: Rainer Machne [mailto:ra...@tb...] 
> Sent: 06 February 2009 09:16
> To: Eric Fernandez
> Subject: RE: [SOSlib-discuss] memory exhaustion creating 
> odeModels[Scanned]
> 
> 
> Maybe you can update to a later release or SVN version of 
> libSBML, I remember at least one memory leak in ASTNode in 
> the first 3.x.x versions.
> Rainer

Hi,

My mistake, it seems the memory run-out occurs when creating
odeModel_t*:

This does work:

int main()
{

  int ctit;
  string modelFilename = "../../models/CC.xml";
  SBMLDocument_t *d;
  Model_t *m;

  d = readSBML(modelFilename.c_str());
  m = SBMLDocument_getModel(d);

  for(ctit = 0; ctit != 10000; ++ctit)
    {
      m = SBMLDocument_getModel(d); //DOES NOT EXHAUST!!
    }
}

but this segfaults after only 114 created instances of odeModels:

int main()
{

  int ctit;
  string modelFilename = "../../models/CC.xml";
  SBMLDocument_t *d;
  Model_t *m;

  d = readSBML(modelFilename.c_str());
  m = SBMLDocument_getModel(d);

  for(ctit = 0; ctit != 10000; ++ctit)
    {
      m = SBMLDocument_getModel(d); //DOES NOT EXHAUST!!
      odeModel_t* om = ODEModel_create(m); //SEGFAULT!!
    }
}

Is an odeModel structure that big, or is there a possible memleak ?

Eric

[SOSlib-discuss] [Fwd: RE: memory exhaustion creating odeModels[Scanned]]

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

Sorry, the last two emails didn't make it to the list. Seems the problem
came from libSBML (whew).

Re: [SOSlib-discuss] memory exhaustion creating odeModels[Scanned]

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

> Eric,
> 
> Did you solve your problem yet? One problem is that your are 
> creating the model directrly from file, which means that for 
> each instance you have a separate copy of the SBML model 
> structure, while in principle you would only need one SBML 
> model and could create the odeModel with
> 
> odeModel_t* = ODEModel_create(Model_t *sbml)
> 
> I guess that would save a lot of memory, esp. if the SBML has 
> additional annotations!
> 
> Rainer

Hi Rainer,

Thanks a lot for this answer, and sorry too not to return to you yet.
Anyway, I wanted to create many separate models because I wanted to
change them independently on the fly (using setVariableValue()). Hence I
thought it was possible to create hundreds of models from file and play
with each of them. But I memory out after only 92 ODEModel created
(model SBML size is 190kB), which I find very low. I tried using
ODEModel_create(Model_t *sbml) but I memory out after 115 models.
I'll try to find a workaround.

Regards,
Eric

Re: [SOSlib-discuss] memory exhaustion creating odeModels

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

Eric,

I am so sorry! I completely forgot about this email over the holidays 
(when there was too much stress to reply immediately, als because i 
didnt think of the simple answer given below at first).

> odeModel_t* = ODEModel_createFromFile("model.xml");
>
> Is that data structure that big ? Of course that depends on the size of
> the model (190kB in my case),

Did you solve your problem yet? One problem is that your are creating the 
model directrly from file, which means that for each instance you have a 
separate copy of the SBML model structure, while in principle you would 
only need one SBML model and could create the odeModel with

odeModel_t* = ODEModel_create(Model_t *sbml)

I guess that would save a lot of memory, esp. if the SBML has additional 
annotations!

Rainer


On Mon, 15 Dec 2008, Eric Fernandez wrote:

> Hi,
>
> I get a segfault when trying to create from file around 70 odeModel*_t:
>
> odeModel_t* = ODEModel_createFromFile("model.xml");
>
> Is that data structure that big ? Of course that depends on the size of
> the model (190kB in my case), but I am surprised to get a segfault.
>
> Any advice ? I know I could only use pointers, but I'd like to make
> "evolve" these models within a cell population, therefore I thought it
> would be better to have one model per cell. If there is no other
> workaround I'll change the parameters "on the fly" before doing an
> integration and keep one model pointer for all cells.
>
> Thanks,
> Eric
>
> ------------------------------------------------------------------------------
> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
> The future of the web can't happen without you.  Join us at MIX09 to help
> pave the way to the Next Web now. Learn more and register at
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
> _______________________________________________
> sbmlsolver-discuss mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-discuss
>

[SOSlib-discuss] memory exhaustion creating odeModels

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

Hi,

I get a segfault when trying to create from file around 70 odeModel*_t:

odeModel_t* = ODEModel_createFromFile("model.xml");

Is that data structure that big ? Of course that depends on the size of
the model (190kB in my case), but I am surprised to get a segfault.

Any advice ? I know I could only use pointers, but I'd like to make
"evolve" these models within a cell population, therefore I thought it
would be better to have one model per cell. If there is no other
workaround I'll change the parameters "on the fly" before doing an
integration and keep one model pointer for all cells.

Thanks,
Eric

Re: [SOSlib-discuss] equivalent to observablesArray ?[Scanned]

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

> -----Original Message-----
> From: Rainer Machne [mailto:ra...@tb...] 
> Sent: 30 October 2008 14:52
> To: Eric Fernandez
> Subject: Re: [SOSlib-discuss] equivalent to observablesArray 
> ?[Scanned]
> 
> The way to interface variables/parameters of the derived ODE 
> Model is as 
> follows:
> 
> 1) Get a variableIndex_t from the ODEModel, each by the function
> 
> 
> variableIndex_t *ODEModel_getVariableIndex (odeModel_t *om, 
> const char 
> *symbol)
> 
> To map this from the SBML model, you could set the string in above 
> function:
> 	symbol = Species_getId(species)
> 


Hi,

And for people interested don't forget: you need to free a variable
Index structure returned by ODEModel_getVariableIndex() after use using
VariableIndex_free(vi) otherwise you'll rapidly run out of memory (if
you use it in loops like I did).

Therefore: integratorInstance_getValue(engine,
ODEModel_getVariableIndex(om, symbol));
is a big no-no!

Eric

Re: [SOSlib-discuss] copyVariableState() and setVariableValue() issues[Scanned]

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

Hi Rainer,

A stricter (lower) error tolerance has helped a lot, convergence issues
disappear for the subsequent steps when using the non Jacobian solver.
However, I cannot use Jacobian at all for the first step, it never
converges succesfully. You must be right regarding the particular state
of the initial conditions.

Regards,
Eric

> -----Original Message-----
> From: Rainer Machne [mailto:ra...@tb...] 
> Sent: 17 November 2008 01:45
> To: Eric Fernandez
> Cc: sbm...@li...
> Subject: Re: [SOSlib-discuss] copyVariableState() and 
> setVariableValue() issues[Scanned]
> 
> Hi Eric,
> 
> sorry for the late reply, I have just moved to Japan for a year.
> 
> On Sat, 8 Nov 2008, Eric Fernandez wrote:
> 
> >
> > Hi,
> >
> > I reply to myself regarding the usage of setVariableValue() 
> : indeed 
> >it works as intended. However, I get the same problems than with
> >copyVariableState(): when the integration is solved with a Jacobian 
> >matrix, I get a convergence test error as soon as I do the first 
> >integration step. I wonder why there is a problem, shouldn't an 
> >integrator instance behave normally if the initial conditions are 
> >changed?
> 
> I guess, I should have a look at copyVariableState, if it 
> still works as intended after all the changes made.
> 
> However, I think the situation you described can happen. The 
> new initial conditions might put the system close to some 
> hard-to-solve stiff state, and a running solver might have 
> it's internal time steps etc. already set-up for this 
> situation, while a newly starting solver has problems with 
> the same conditions. Maybe you could try to play with the 
> error tolerances and printstep size?
> 
> But you are right, the CVodeReInit caused by events should 
> have the same or similar effects on an already running itnegrator.
> 
> Are there any news regarding this problem?
> 
> Rainer

Re: [SOSlib-discuss] copyVariableState() and setVariableValue() issues[Scanned]

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

Hi,

Oh well congratulations! Are you joining some famous Systems Biology
group there ?
I wish you a very good time there. With excellent and healthy food!

Regards,
Eric 

> -----Original Message-----
> From: Rainer Machne [mailto:ra...@tb...] 
> Sent: 17 November 2008 01:45
> To: Eric Fernandez
> Cc: sbm...@li...
> Subject: Re: [SOSlib-discuss] copyVariableState() and 
> setVariableValue() issues[Scanned]
> 
> Hi Eric,
> 
> sorry for the late reply, I have just moved to Japan for a year.
> 
> On Sat, 8 Nov 2008, Eric Fernandez wrote:
> 
> >
> > Hi,
> >
> > I reply to myself regarding the usage of setVariableValue() 
> : indeed 
> >it works as intended. However, I get the same problems than with
> >copyVariableState(): when the integration is solved with a Jacobian 
> >matrix, I get a convergence test error as soon as I do the first 
> >integration step. I wonder why there is a problem, shouldn't an 
> >integrator instance behave normally if the initial conditions are 
> >changed?
> 
> I guess, I should have a look at copyVariableState, if it 
> still works as intended after all the changes made.
> 
> However, I think the situation you described can happen. The 
> new initial conditions might put the system close to some 
> hard-to-solve stiff state, and a running solver might have 
> it's internal time steps etc. already set-up for this 
> situation, while a newly starting solver has problems with 
> the same conditions. Maybe you could try to play with the 
> error tolerances and printstep size?
> 
> But you are right, the CVodeReInit caused by events should 
> have the same or similar effects on an already running itnegrator.
> 
> Are there any news regarding this problem?
> 
> Rainer
> 
> >
> >
> > Eric
> >
> >
> > -----Original Message-----
> > From: Eric Fernandez [mailto:efe...@ph...]
> > Sent: Fri 11/7/2008 12:36 PM
> > To: sbm...@li...
> > Subject: [SOSlib-discuss] copyVariableState() and 
> setVariableValue() 
> > issues[Scanned]
> >
> > Hi,
> >
> > I am wondering if there are not issues with copyVariableState(), 
> > probably I do not use it correctly.
> >
> > I am trying to run a model (very large and complex, using 
> many events) 
> > for a couple of steps, and then want to transfer the 
> species values to 
> > a new, fresh integrator instance, and run again using the final 
> > variable state of the first integrator instance as the initial 
> > conditions of the second integrator instance. (That is to 
> simulate a 
> > checkpoint.)
> >
> > First method I use is copyVariableState(). The problem is that very 
> > often I get convergence test errors and other weird stuff (some 
> > species becoming negative) that happen for particular values of the 
> > steps used in the first instance. Some step values work 
> like a charm, 
> > some others lead to these issues. Am I doing this wrong ?
> >
> > The second method, was to dump all the species names/values 
> at the end 
> > of the first instance integration in an array. Then I 
> create a second 
> > integrator instance and use a loop over my array to initialise all 
> > corresponding values, using setVariableValue(). The really 
> weird stuff 
> > here, is that when I start again the integrator, it is as if it were
> > reset: it uses the initial conditions of the model, not the one set 
> > with setVariableValue(). Is it normal ? Or do I make 
> something wrong here ?
> >
> > Thanks for the help,
> > 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] copyVariableState() and setVariableValue() issues

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

Hi Eric,

sorry for the late reply, I have just moved to Japan for a year.

On Sat, 8 Nov 2008, Eric Fernandez wrote:

>
> Hi,
>
> I reply to myself regarding the usage of setVariableValue() : indeed it 
>works as intended. However, I get the same problems than with 
>copyVariableState(): when the integration is solved with a Jacobian 
>matrix, I get a convergence test error as soon as I do the first 
>integration step. I wonder why there is a problem, shouldn't an 
>integrator 
>instance behave normally if the initial conditions are changed?

I guess, I should have a look at copyVariableState, if it still works as 
intended after all the changes made.

However, I think the situation you described can happen. The new initial 
conditions might put the system close to some hard-to-solve stiff state, 
and a running solver might have it's internal time steps etc. already 
set-up for this situation, while a newly starting solver has problems with 
the same conditions. Maybe you could try to play with the error tolerances 
and printstep size?

But you are right, the CVodeReInit caused by events should have the same 
or similar effects on an already running itnegrator.

Are there any news regarding this problem?

Rainer

>
>
> Eric
>
>
> -----Original Message-----
> From: Eric Fernandez [mailto:efe...@ph...]
> Sent: Fri 11/7/2008 12:36 PM
> To: sbm...@li...
> Subject: [SOSlib-discuss] copyVariableState() and setVariableValue() issues[Scanned]
>
> Hi,
>
> I am wondering if there are not issues with copyVariableState(),
> probably I do not use it correctly.
>
> I am trying to run a model (very large and complex, using many events)
> for a couple of steps, and then want to transfer the species values to a
> new, fresh integrator instance, and run again using the final variable
> state of the first integrator instance as the initial conditions of the
> second integrator instance. (That is to simulate a checkpoint.)
>
> First method I use is copyVariableState(). The problem is that very
> often I get convergence test errors and other weird stuff (some species
> becoming negative) that happen for particular values of the steps used
> in the first instance. Some step values work like a charm, some others
> lead to these issues. Am I doing this wrong ?
>
> The second method, was to dump all the species names/values at the end
> of the first instance integration in an array. Then I create a second
> integrator instance and use a loop over my array to initialise all
> corresponding values, using setVariableValue(). The really weird stuff
> here, is that when I start again the integrator, it is as if it were
> reset: it uses the initial conditions of the model, not the one set with
> setVariableValue(). Is it normal ? Or do I make something wrong here ?
>
> Thanks for the help,
> 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] copyVariableState() and setVariableValue() issues

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

Hi, 

I reply to myself regarding the usage of setVariableValue() : indeed it works as intended. However, I get the same problems than with copyVariableState(): when the integration is solved with a Jacobian matrix, I get a convergence test error as soon as I do the first integration step. I wonder why there is a problem, shouldn't an integrator instance behave normally if the initial conditions are changed?


Eric


-----Original Message-----
From: Eric Fernandez [mailto:efe...@ph...]
Sent: Fri 11/7/2008 12:36 PM
To: sbm...@li...
Subject: [SOSlib-discuss] copyVariableState() and setVariableValue() issues[Scanned]
 
Hi,

I am wondering if there are not issues with copyVariableState(),
probably I do not use it correctly.

I am trying to run a model (very large and complex, using many events)
for a couple of steps, and then want to transfer the species values to a
new, fresh integrator instance, and run again using the final variable
state of the first integrator instance as the initial conditions of the
second integrator instance. (That is to simulate a checkpoint.)

First method I use is copyVariableState(). The problem is that very
often I get convergence test errors and other weird stuff (some species
becoming negative) that happen for particular values of the steps used
in the first instance. Some step values work like a charm, some others
lead to these issues. Am I doing this wrong ?

The second method, was to dump all the species names/values at the end
of the first instance integration in an array. Then I create a second
integrator instance and use a loop over my array to initialise all
corresponding values, using setVariableValue(). The really weird stuff
here, is that when I start again the integrator, it is as if it were
reset: it uses the initial conditions of the model, not the one set with
setVariableValue(). Is it normal ? Or do I make something wrong here ?

Thanks for the help,
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] equivalent to observablesArray ?[Scanned]

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

Hi Rainer,

Sorry for this late reply, I was away. Thanks a lot for these info.
These suggestions look good to me (in particular
ODEModel_getVariableIndexFromSBase).

Eric 

> -----Original Message-----
> From: Rainer Machne [mailto:ra...@tb...] 
> Sent: 30 October 2008 14:52
> To: Eric Fernandez
> Subject: Re: [SOSlib-discuss] equivalent to observablesArray 
> ?[Scanned]
> 
> Eric Fernandez wrote:
> > Hi,
> > 
> > I shall answer to myself. What I want is returned by:
> > 
> > for ( int i = 0; i != Model_getNumSpecies(om->m); i++ )
> 
> Hi Eric,
> 
> We should probably introduce an interface function for om->m.
> This SBML model, btw, is exactly the model from the input file.
> 
> I have jsut added to CVS two new functions:
> 
> 	const Model_t *ODEModel_getInputSBMLl(om)
> 
> returns the pointer om->m, i.e. the input SBML. And
> 
> 	const Model_t *ODEModel_getODESBMLl(om)
> 
> returns the pointer om->simple, which is an internally 
> produced SBML model where all reactions have been replaced by 
> SBML rate rules.
> 
> 
> >     {
> >       Species_t *species = Model_getSpecies(om->m, i);
> >       cout << Species_getId(species) << " ";
> >     }
> > 
> > (the same way the observables were built before).
> > 
> 
> 
> Just a warning for potential other readers:
> 
> Above code to get the Species from the input SBML model is not really 
> relevant for getting values from the derived ODE model or the 
> integrator:
> The order of species, parameters, rules and reactions in the 
> input SBML 
> DOES NOT correspond to the order of 1) ODE variables, 2) assigned 
> variables, 3) constants in odeModel (om->names) and cvodeData 
> (data->values). There is no direct mapping between SBML and 
> ODE models.
> 
> The way to interface variables/parameters of the derived ODE 
> Model is as 
> follows:
> 
> 1) Get a variableIndex_t from the ODEModel, each by the function
> 
> 
> variableIndex_t *ODEModel_getVariableIndex (odeModel_t *om, 
> const char 
> *symbol)
> 
> To map this from the SBML model, you could set the string in above 
> function:
> 	symbol = Species_getId(species)
> 
> There are however various other functions to retrieve 
> specific variables 
> from the ODE model. Now, that i am writing this, maybe we can 
> introduce 
> simple convenience functions, which allow to get the 
> variableIndex just 
> via SBML species, parameter, compartment or reaction pointers, e.g.:
> 
> 	ODEModel_getVariableIndexFromSBase
> 
> Interested? It is rather trivial though.
> 
> 2) Use this variableIndex to get the current values from the 
> integrator by
> 
> IntegratorInstance_getVariableValue(integratorInstance_t *engine, 
> variableIndex_t *vi)
> 
> 
> I guess you know that, but maybe it's helpful for others.
> 
> Rainer

[SOSlib-discuss] copyVariableState() and setVariableValue() issues

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

Hi,

I am wondering if there are not issues with copyVariableState(),
probably I do not use it correctly.

I am trying to run a model (very large and complex, using many events)
for a couple of steps, and then want to transfer the species values to a
new, fresh integrator instance, and run again using the final variable
state of the first integrator instance as the initial conditions of the
second integrator instance. (That is to simulate a checkpoint.)

First method I use is copyVariableState(). The problem is that very
often I get convergence test errors and other weird stuff (some species
becoming negative) that happen for particular values of the steps used
in the first instance. Some step values work like a charm, some others
lead to these issues. Am I doing this wrong ?

The second method, was to dump all the species names/values at the end
of the first instance integration in an array. Then I create a second
integrator instance and use a loop over my array to initialise all
corresponding values, using setVariableValue(). The really weird stuff
here, is that when I start again the integrator, it is as if it were
reset: it uses the initial conditions of the model, not the one set with
setVariableValue(). Is it normal ? Or do I make something wrong here ?

Thanks for the help,
Eric

Re: [SOSlib-discuss] equivalent to observablesArray ?

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

Hi Eric,

In general, the IntegratorInstance_getVariableValue is the only way an 
external application is supposed to use to retrieve values from the model 
between IntegratorInstance_integrateOneStep calls.

In the new version (CVS) this function also makes sure that the retrieved 
values are up-to-date (by evaluating assignment rules for values that 
might have changed)!

Calling engine->data->value[i] directly is not considered save (although 
your way gave correct results!), and also such internal data structures 
might change with upcoming releases, while the interface function should 
stay the same!


The observables array was used to optimize the updating of rules, i.e. to 
only update assignment rules required for a set of "observables", and 
thereby consider assignments that are already up-to-date. Since there is 
no restriction on ordering of rules in the new SBML version, the old 
approach wouldn't have worked that easily anymore.
Also the observables could have let to _getVariableValue returning wrong 
values, if the user/application is not aware of the 
observables-requirement.

Now this updating of remaining rules has been moved to _getVariableValue 
interface function, which only calls it once between _integrateOneStep and 
remembers that rules are up-to-date now.
And for the vast majority of models there would be no increase in 
efficiency to restrict this update to a set of observables.

Thus, efficiency-wise the observables array is not necessary anymore. You 
can just use _getVariableValue for any value you like.


It is however a design decision. Do we want to provide direct access at 
least to data->value ?

In that case, I could reintroduce the observables, which an application 
has to preset to make sure these are kept up-to-date independent of 
calling _getVariableValue.


Opinions?


Rainer



On Mon, 27 Oct 2008, Eric Fernandez wrote:

> Hi again :)
>
> I have a question regarding the recent CVS version.
>
> Before it was possible to filter out model parameters from model species
> using :
>
> if (om->observablesArray[i]) {
>   fprintf(outfile, "%g ", engine->data->value[i]);
> }
>
> but now the observablesArray has disappeared. How is it possible to get
> an output equivalent to previous version?
>
> Thanks,
> 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] equivalent to observablesArray ?[Scanned]

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

Hi,

I shall answer to myself. What I want is returned by:

for ( int i = 0; i != Model_getNumSpecies(om->m); i++ )
    {
      Species_t *species = Model_getSpecies(om->m, i);
      cout << Species_getId(species) << " ";
    }

(the same way the observables were built before).

So I can use this code in my own program, keep that list of species and
use getVariableValues() to retrieve the values I want!

Thanks,
Eric

> -----Original Message-----
> From: Eric Fernandez [mailto:efe...@ph...] 
> Sent: 28 October 2008 10:36
> To: sbm...@li...
> Subject: Re: [SOSlib-discuss] equivalent to observablesArray 
> ?[Scanned]
> 
> Hi Rainer,
> 
> No, I think this is a good decision, and I would not 
> recommend to reintroduce observables if they are unsafe and 
> may change in the future.
> As a C++ programmer, I am also supporting the hiding of 
> internal implementation and give a public, restricted 
> interface to users.
> Actually I just followed the structure of the odeSolver 
> example that is in the CVS, and which uses this method to 
> dump the variable values into a file, so I kept this method until now.
> 
> Now, I would like to dump the variable values only and not 
> the parameters into a file (the same way than odeSolver 
> does). If I use getVariableValues(), I would need to have an 
> array with these value names (or their index). Is it possible 
> to have this list automatically?
> Let's say I change my SBML model, I would like to avoid 
> changing the list of variable names in my program too.
> 
> Is it possible to have either:
> - a "getAllVariableValues()" function that would 
> automatically return all variable values and names in an array
> - a function that returns the variable names from the 
> odeModel structure ?
> 
> Thanks a lot,
> Eric 

Re: [SOSlib-discuss] equivalent to observablesArray ?[Scanned]

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

Hi Rainer,

No, I think this is a good decision, and I would not recommend to
reintroduce observables if they are unsafe and may change in the future.
As a C++ programmer, I am also supporting the hiding of internal
implementation and give a public, restricted interface to users.
Actually I just followed the structure of the odeSolver example that is
in the CVS, and which uses this method to dump the variable values into
a file, so I kept this method until now.

Now, I would like to dump the variable values only and not the
parameters into a file (the same way than odeSolver does). If I use
getVariableValues(), I would need to have an array with these value
names (or their index). Is it possible to have this list automatically?
Let's say I change my SBML model, I would like to avoid changing the
list of variable names in my program too.

Is it possible to have either:
- a "getAllVariableValues()" function that would automatically return
all variable values and names in an array
- a function that returns the variable names from the odeModel structure
?

Thanks a lot,
Eric 

> -----Original Message-----
> From: Eric Fernandez 
> Sent: 28 October 2008 10:08
> To: 'Rainer Machne'
> Subject: RE: [SOSlib-discuss] equivalent to observablesArray 
> ?[Scanned]
> 
> Hi Rainer,
> 
> No, I think this is a good decision, and I would not 
> recommend to reintroduce observables if they are unsafe and 
> may change in the future. As a C++ programmer, I am also 
> supporting the hiding of internal implementation and give a 
> public, restricted interface to users. Actually I just 
> followed the structure of the odeSolver example that is in 
> the CVS, and which uses this method to dump the variable 
> values into a file, so I kept this method until now.
> 
> Now, I would like to dump the variable values only and not 
> the parameters into a file (the same way than odeSolver 
> does). If I use getVariableValues(), I would need to have an 
> array with these value names (or their index). Is it possible 
> to have this list automatically? Let's say I change my SBML 
> model, I would like to avoid changing the list of variable 
> names in my program too.
> 
> Is it possible to have either:
> - a "getAllVariableValues()" function that would 
> automatically return all variable values and names in an array
> - a function that returns the variable names from the 
> odeModel structure ?
> 
> Thanks a lot,
> Eric

Re: [SOSlib-discuss] new error 100008 Model doesn't provide a value

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

On Mon, 27 Oct 2008, Eric Fernandez wrote:

> Hi,
>
> I have recompiled a recent CVS version of SOSlib and noticed that error
> in my model:
> Error     100008  SBML Model doesn't provide a value for SBML ID sink,
> value defaults to 0!
>
> Before this was just a warning, is it normal it has now become an error?
> Besides, if the engine decides to provide a default value, shouldn't it
> be a warning only?

Hi Eric,

I implemented this stricter behaviour, because in the strict SBML-sense 
the model is underspecified and should not be integrated. This defaulting 
to 0 used to be done to avoid a solver-crash at a later point.

I am not sure, but I tend to leave it as an error, as the 
integration results are depending on an arbitrary choice. E.g. in 
earlier SBML versions a missing compartment size defaulted to 1; with 0 on 
the other hand the value could lead to illegal divisions.

Opinions?

Rainer


>
> Thanks,
> 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] equivalent to observablesArray ?

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

Hi again :)

I have a question regarding the recent CVS version.

Before it was possible to filter out model parameters from model species
using :

 if (om->observablesArray[i]) {
   fprintf(outfile, "%g ", engine->data->value[i]);
}

but now the observablesArray has disappeared. How is it possible to get
an output equivalent to previous version?

Thanks,
Eric

[SOSlib-discuss] new error 100008 Model doesn't provide a value

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

Hi,

I have recompiled a recent CVS version of SOSlib and noticed that error
in my model:
 Error     100008  SBML Model doesn't provide a value for SBML ID sink,
value defaults to 0!

Before this was just a warning, is it normal it has now become an error?
Besides, if the engine decides to provide a default value, shouldn't it
be a warning only?

Thanks,
Eric

Re: [SOSlib-discuss] Resetting Cvode when using integratorInstance_setVariableValue()

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

Hi Eric,

Yes, you are right here! We had realized this problem - unlike we 
thought/hoped previously such discontinuities in the right-hand-side also 
require re-initialization of the solver.

Actually, in the current CVS the IntegratorInstance_setVariableValue() 
responds directly to the ResetCvodeOnEvent option (instead of the event 
processing function as previously).

Now that you provide an example where this really shows the expected 
problems, I guess we should rename this option, or remove it completely 
and use resetting as default behaviour.

Thanks,
Rainer

On Sat, 25 Oct 2008, Eric Fernandez wrote:

> Hi,
>
> I think I have solved an issue using integratorInstance_setVariableValue(). In one of my simulations, I was "injecting" at every step of an integration (at each loop of the while(!IntegratorInstance_timeCourseCompleted(engine){IntegratorInstance_integrateOneStep(engine)}) of a program similar to the odeSolver) the value of one parameter of my model, to simulate the timecourse of a drug injected in a cell, which was read from an external file, as a map<double, double> representing <time, drug_concentration>.
>
> The first simulations leaded to many integration solving errors such as "At t = 5.01293 and h = 5.14192e-08, the error test failed repeatedly or with |h| = hmin.", etc...
>
> I had the idea to use the same technique than for the ResetCvodeOnEvent, using engine->valid = 0;  at each step of the integration, because after all the effect of setVariableValue is equivalent to an event: forcing arbitrarily the change of a model variable value. And then it worked wonderfully with no error at all! I would suggest that this Reset should therefore be performed after each use of integratorInstance_setVariableValue(). Otherwise, is there any reason not to do it ? I did not notice significant slowdown. Rainer, what do you think ? I did not want to do any change to the CVS before you could review this "trick" as I was unsure if there may be some collateral damage (can it lead to undetected false integration values ?) forcing a reset in this case.
>
> Regards,
> Eric
>

[SOSlib-discuss] Resetting Cvode when using integratorInstance_setVariableValue()

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

Hi,

I think I have solved an issue using integratorInstance_setVariableValue(). In one of my simulations, I was "injecting" at every step of an integration (at each loop of the while(!IntegratorInstance_timeCourseCompleted(engine){IntegratorInstance_integrateOneStep(engine)}) of a program similar to the odeSolver) the value of one parameter of my model, to simulate the timecourse of a drug injected in a cell, which was read from an external file, as a map<double, double> representing <time, drug_concentration>.

The first simulations leaded to many integration solving errors such as "At t = 5.01293 and h = 5.14192e-08, the error test failed repeatedly or with |h| = hmin.", etc...

I had the idea to use the same technique than for the ResetCvodeOnEvent, using engine->valid = 0;  at each step of the integration, because after all the effect of setVariableValue is equivalent to an event: forcing arbitrarily the change of a model variable value. And then it worked wonderfully with no error at all! I would suggest that this Reset should therefore be performed after each use of integratorInstance_setVariableValue(). Otherwise, is there any reason not to do it ? I did not notice significant slowdown. Rainer, what do you think ? I did not want to do any change to the CVS before you could review this "trick" as I was unsure if there may be some collateral damage (can it lead to undetected false integration values ?) forcing a reset in this case.

Regards,
Eric

Re: [SOSlib-discuss] Java api available?

[Richard A. <ra...@st...>]

Hi Rainer,
  Thanks for your quick reply - unfortunately I don't have the  
resources to write a full Java binding but as  the modellers I'm  
working for want quite a lot of the functionality your library  
provides it looks like I'll have to get stuck in, even if its just for  
high level interface functions to begin with.
  I've not done Java->C bindings before, but I think it would be fine  
to contribute anything I produce.
  Thanks again,
           Richard

> Hi Richard,
>
> The next releases will hopefully contain swig-based bindings for perl,
> which probably could be used as a template for generating Java bindings.
> Unfortunately, we ourselves have no experience with Java!
>
> The CellDesigner team created their own Java bindings, but only for
> high-level interface functions, and there have been a few posts to this
> list of groups who created their own Java bindings for SOSlib.
> Is there any interest in contributing this work or helping us to extend
> it to a swig-interface to Java?
>
> I hope that the swig files for perl will be in CVS soon.
> Maybe, Christoph, could you outline the necessary steps for creating a
> Java interface?
>
> Rainer
>
>
>
> On Tue, 21 Oct 2008, Richard Adams wrote:
>
>> Hello,
>> I'm writing a Java based GUI for biologists in our group wishing to
>> run simulations and wondered if there were any Java bindings to
>> soslib? I noticed that
>> CellDesigner (which is written in Java) uses soslib but couldn't find
>> much from Googling.
>>
>> Thanks,
>>
>> Richard
>>
>> -- 
>> Dr Richard Adams
>> Senior Software Developer,
>> Computational Systems Biology Group,
>> University of Edinburgh
>> Tel: 0131 650 8281
>> email : ric...@ed...
>>
>> -- 
>> The University of Edinburgh is a charitable body, registered in
>> Scotland, with registration number SC005336.
>>
>>
>>
>> -------------------------------------------------------------------------
>> 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
>>



-- 
Dr Richard Adams
Senior Software Developer,
Computational Systems Biology Group,
University of Edinburgh
Tel: 0131 650 8281
email : ric...@ed...

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

Re: [SOSlib-discuss] Java api available?

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

Hi Richard,

The next releases will hopefully contain swig-based bindings for perl, 
which probably could be used as a template for generating Java bindings.
Unfortunately, we ourselves have no experience with Java!

The CellDesigner team created their own Java bindings, but only for 
high-level interface functions, and there have been a few posts to this 
list of groups who created their own Java bindings for SOSlib.
Is there any interest in contributing this work or helping us to extend 
it to a swig-interface to Java?

I hope that the swig files for perl will be in CVS soon.
Maybe, Christoph, could you outline the necessary steps for creating a 
Java interface?

Rainer



On Tue, 21 Oct 2008, Richard Adams wrote:

> Hello,
> I'm writing a Java based GUI for biologists in our group wishing to
> run simulations and wondered if there were any Java bindings to
> soslib? I noticed that
> CellDesigner (which is written in Java) uses soslib but couldn't find
> much from Googling.
>
> Thanks,
>
> Richard
>
> -- 
> Dr Richard Adams
> Senior Software Developer,
> Computational Systems Biology Group,
> University of Edinburgh
> Tel: 0131 650 8281
> email : ric...@ed...
>
> -- 
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>
>
>
> -------------------------------------------------------------------------
> 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] Java api available?

[Richard A. <ra...@st...>]

Hello,
I'm writing a Java based GUI for biologists in our group wishing to  
run simulations and wondered if there were any Java bindings to  
soslib? I noticed that
CellDesigner (which is written in Java) uses soslib but couldn't find  
much from Googling.

Thanks,

Richard

-- 
Dr Richard Adams
Senior Software Developer,
Computational Systems Biology Group,
University of Edinburgh
Tel: 0131 650 8281
email : ric...@ed...

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

[SOSlib-discuss] Java api available?

[Richard A. <ra...@st...>]

Hello,
I'm writing a Java based GUI for biologists in our group wishing to  
run simulations and wondered if there were any Java bindings to  
soslib? I noticed that
CellDesigner (which is written in Java) uses soslib but couldn't find  
much from Googling.

Thanks,

Richard

-- 
Dr Richard Adams
Senior Software Developer,
Computational Systems Biology Group,
University of Edinburgh
Tel: 0131 650 8281
email : ric...@ed...

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

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

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

> -----Original Message-----
> From: Rainer Machne [mailto:ra...@tb...] 
> Sent: 20 October 2008 15:25
> To: Eric Fernandez
> Cc: Eva Sciacca; sbm...@li...
> Subject: Re: [SOSlib-discuss] Problem on simulating models 
> with triggers andevents[Scanned]
> 
> Hi Eva,
> 
> Eric's hints are correct. SOSlib can handle SBML events, it 
> is however not fully SBML-conformant. Here some more background:

And just to add up to Rainer's excellent explanation, as a rule of
thumb, I usually use a PrintStep of ten times the Time of the
simulation. Mileage may vary, depending on how stiff your model is. I
can go as low as 5 times, but resolution becomes poor. Below 2 times I
definitely get skipped events, therefore some catastrophic result. It is
recommended to test different values, to graph the output (using grace
for instance) and check if everything is alright. Our models heavily use
events and oscillators and so far we never had any issue when using a
PrintStep of at least 10 times the total simulation Time.

Hope this helps,
Eric