sbmlsolver-devel — developer's email list for the SBML ODE Solver Library

Re: [SOSlib-devel] Problem with senstivities

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

Hi Eryk,


you wrote:

> the loop includes:
> {
> change of the parameters

... and ...

> What I observe and call a problem is that every new simulator run in
> the loop generates increasing sensitivity values for the same
> parameter values and model.

For the first statement `change of the parameters' it would be obvious, 
that sensitivities change, I guess the sensitivities can also change their 
sign, e.g. if during the parameter change you cross a bifurcation point.

This can of course also happen for parameters that you have not changed! 
I.e. you change parameter A across a bifurcation point. Then the behaviour 
of the system completely changes. Then of course also the sensitivities to 
unchanged parameters change. They can even change their sign.

Do you also observe the change of sensitivities if you DO NOT change the 
parameters between the runs?

Rainer











On Tue, 15 Aug 2006, W Eryk Wolski wrote:

> Hi,
>
> I am running the solver in a loop.
>
> the loop includes:
> {
> change of the parameters
> running the solver
> and a call to IntegratorInstance_reset(integratorInstance);
> }
>
> What I observe and call a problem is that every new simulator run in
> the loop generates increasing sensitivity values for the same
> parameter values and model.
>
> The following output are the date stored in:
>
> integratorInstance->data->sensitivity
> entries
> integratorInstance->data->nsens, integratorInstance->data->neq
>
> first iteration
>
> parameters:  par[0] 2.000000  par[1] 8.000000  par[2] 10.000000
> par[3] 0.100000  par[4] 2.000000
>
> 24.33599	-12.44311	-1.60336	0.28326	26.31235	-0.12182	0.00000	0.00000
> -24.33599	12.44311	1.60336	-0.28326	-26.31235	0.12182	0.00000	11.93225
> 11.93225	-4.09705	-0.54112	0.08923	8.68924	-0.04727	0.00000	-7.76276
> -7.76276	2.05021	0.27103	-0.04458	-4.34843	0.02380	0.00000	-4.16949
> -4.16949	2.04684	0.27009	-0.04465	-4.34081	0.02346	0.00000	-0.26712
> -0.26712	-0.45221	-0.06041	0.00965	0.95925	-0.00565	0.00000	-1.57271
>
>
> while the 10 iteration:
>
> -1394.82594	399.44848	59.25448	-19.98846	-2225.46440	3.11907	0.00000	0.00000
> 1394.82594	-399.44848	-59.25448	19.98846	2225.46440	-3.11907	0.00000	-21877.33372
> -21877.33372	6547.28853	971.83061	-324.87728	-36996.03248	52.60350	0.00000	-2206.49496
> -2206.49496	666.20014	98.97768	-33.06429	-3791.30589	5.39430	0.00000	24083.82868
> 24083.82868	-7213.48867	-1070.80829	357.94157	40787.33837	-57.99780	0.00000	-21953.82949
> -21953.82949	6578.30322	976.54971	-326.41598	-37205.87555	52.90915	0.00000	12235.00898
>
>
>
> I hope that the problem statement is clear but I am happy to answer
> more questions.
> I am looking forward to suggestions.
>
> Eryk
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> sbmlsolver-devel mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>

Re: [SOSlib-devel] Piecewise mathML element problem.

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

Hi Nicolas,

I think, you are using a wrong piecewise statement. In the MathML for each 
piece, the result must come before the condition not after the condition 
as in your piecewise construct.

I have communicated with the other EBI Nicolas about this a month ago, 
maybe he can sent you the more detailed example I had sent back then.

See
http://www.zvon.org/xxl/MathML/Output/el_piecewise.html
for correct piecewise elements.


This was an error in an early version of the SBML test suite or in some 
official SBML example models. So the older versions of the 
odeSolver was also wrong because we were using the test suite and official 
SBML examples as a standard.

Then there is another problem with your example. You use a piecewise with 
the conditions 
time == 150 and
time == 120
so the whole piecewise is undefined at any other times then exactly 150 or 
120.
So you would need to add a default value (otherwise)!

Then of course equality expressions like this are problematic because 
SOSlib wouldn't detect it unless the printstep is set to a value so 150 
and 120 are output step, or by chance the internal integrator comes 
exactly to this time point. So such an equality expression should rather 
be in an event, which might in future versions of SOSlib be handled by 
exact event detection :)

Maybe we have to care for such cases in SOSlib also for piecewise.

In summary:

In infix output of libSBML/SOSlib
WRONG:
1: species_0000003 =  piecewise(eq(time, 150), 10, eq(time, 120), 5)
CORRECT, E.G.:
1: species_0000003 =  piecewise(10, lt(time, 150), 5, gt(time, 150));


The "correct" example is still problematic and we might have found a bug 
here.
10 befire time 150 and 5 afterwards. Of course this is also not correct, 
because at time 150 its again undefined. Unfortunately SOSlib seems to 
interpret this as 0, issue an error message, but keep integrating, unstead 
of exiting.

Integrating  1.00 |finished. Results stored.
       Error     20107   Piecewise function failed; no true piece
Printing results to XMGrace!

So this is a bug, actually!

Rainer



On Tue, 22 Aug 2006, Nicolas Rodriguez wrote:

> Hi,
>
> I applied the patch below, in fact, I compiled the latest cvs version of 
> SBML_odeSolver.
>
> There is still a problem with the piecewise element apparently.
> I attached to the message the sbml file we are using to do our tests, in case 
> something is wrong with it.
>
> cerveza: test] odeSolver piecewiseTest.xml
>     Error     20107   Piecewise function failed; several true pieces
>     Error     20107   Piecewise function failed; several true pieces
>     Error     20107   Piecewise function failed; several true pieces
> cerveza: test]
>
> May be I am not understanding well how the evaluateAST is working, but it 
> seems to me that you are evaluating half of the piece elements in the current 
> algorithms.
>
> I would see more something like that :
>
> case AST_FUNCTION_PIECEWISE:
>    /** Piecewise: */
>    found = 0;
>    /** Go through all the piece element with 2 AST children for each piece, 
> */
>   for ( i=0;  i < (childnum-1); i = i + 1 )
>    {
>       ASTNode_t  *pieceElement = child(n, i);
>       if ( evaluateAST(child(pieceElement, 0), data) )
>      {
>        found++;
>        result = evaluateAST(child(pieceElement, 1), data);
>      }
>    }
>           // otherwise case
> ...
>
>> Replace the code starting at line 470:
>> 
>>      case AST_FUNCTION_PIECEWISE:
>>        if ( evaluateAST(child(n,0),data) ) {
>>      result = evaluateAST(child(n,1),data);
>>        }
>>        else {
>>      result = evaluateAST(child(n,2),data);
>>        }
>>        break;
>> 
>> with
>> 
>>    case AST_FUNCTION_PIECEWISE:
>>      /** Piecewise: */
>>      found = 0;
>>      /** Go through n pieces with 2 AST children for each piece, */
>>      for ( i=0; i<(childnum-1); i=i+2 )
>>      {
>>        if ( evaluateAST(child(n, i+1), data) )
>>        {
>>      found++;
>>      result = evaluateAST(child(n, i), data);
>>        }
>>      }
>>      /** odd number of AST children: if no piece was true, otherwise 
>> remains */
>>      /* i should be equal to childnum for even number piecewise AST
>>         and equal to childnum-1 for odd numbered piecewise ASTs */
>>      if ( i == childnum-1 && found == 0 )
>>      {
>>        found++;
>>        result = evaluateAST(child(n, i), data);
>>      }
>>      if ( found == 0 )
>>        SolverError_error(ERROR_ERROR_TYPE,
>>              SOLVER_ERROR_AST_EVALUATION_FAILED_PIECEWISE,
>>              "Piecewise function failed; no true piece");
>>      if ( found > 1 )
>>        SolverError_error(ERROR_ERROR_TYPE,
>>              SOLVER_ERROR_AST_EVALUATION_FAILED_PIECEWISE,
>>              "Piecewise function failed; several true pieces");
>>      break;
>> 
>> 
>> ---- end of replacement code ----
>
>

Re: [SOSlib-devel] Problem with senstivities

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

Ok, that's strange then. As the whole solver is freed and initialized with 
the reset function, it cannot be the solver. I can't think of anything 
else at the moment. We will really have to look into that.
Please let us know if you find out anything else about it.

Rainer

On Wed, 16 Aug 2006, W Eryk Wolski wrote:

> On 8/16/06, Rainer Machne <ra...@tb...> wrote:
>> Hi Eryk,
>>
>> this seems to be a bug! Again, I am not in Vienna, have limited access to
>> computers and can't look into the problem. It looks as if the _reset
>> function doesn't reset the sensitivities to 0. I guess, this problem arose
>> because events should not reset sensitivities but keep the values from
>> the last time step befor the solver structures where re-initialized
>> by an event.
>
>
> I was looking at the reset function and it seems to be fine:
>
> the reset function is calling I think the set function and that one is
> calling the
> CvodeData_initialize where the sensitivity matrix in the cvodeData_t
> is set to zero.
>
> Furthermore, what makes me think that this is not the cause of the
> error is that the senstivities not only change the magnitude
> (increase) but also swap the signs.
> I therefor would think that the reason for the error is somewhere else.
> It should be relatively easy to reproduce the error just by running
> the solver in a while loop as I described and printing out the
> sensitivities.
>
>
> cheers
>
>
>
>
>>
>> Maybe you have time to look into it yourself. The function
>> IntegratorInstance_reset probably calls things like CvodeData_initialize
>> at it most somewhere also go into initializing the sensitivities. Both
>> data->sensitivities and results->sensitivities should be set to 0 by the
>> _reset function.
>>
>> If you don't find it yourself and maybe post the problem/solution to this
>> list or even update the CVS with a solution, then I will look into it next
>> week.
>>
>> Rainer
>>
>> On Tue, 15 Aug 2006, W Eryk Wolski wrote:
>>
>>> Hi,
>>>
>>> I am running the solver in a loop.
>>>
>>> the loop includes:
>>> {
>>> change of the parameters
>>> running the solver
>>> and a call to IntegratorInstance_reset(integratorInstance);
>>> }
>>>
>>> What I observe and call a problem is that every new simulator run in
>>> the loop generates increasing sensitivity values for the same
>>> parameter values and model.
>>>
>>> The following output are the date stored in:
>>>
>>> integratorInstance->data->sensitivity
>>> entries
>>> integratorInstance->data->nsens, integratorInstance->data->neq
>>>
>>> first iteration
>>>
>>> parameters:  par[0] 2.000000  par[1] 8.000000  par[2] 10.000000
>>> par[3] 0.100000  par[4] 2.000000
>>>
>>> 24.33599      -12.44311       -1.60336        0.28326 26.31235        -0.12182        0.00000 0.00000
>>> -24.33599     12.44311        1.60336 -0.28326        -26.31235       0.12182 0.00000 11.93225
>>> 11.93225      -4.09705        -0.54112        0.08923 8.68924 -0.04727        0.00000 -7.76276
>>> -7.76276      2.05021 0.27103 -0.04458        -4.34843        0.02380 0.00000 -4.16949
>>> -4.16949      2.04684 0.27009 -0.04465        -4.34081        0.02346 0.00000 -0.26712
>>> -0.26712      -0.45221        -0.06041        0.00965 0.95925 -0.00565        0.00000 -1.57271
>>>
>>>
>>> while the 10 iteration:
>>>
>>> -1394.82594   399.44848       59.25448        -19.98846       -2225.46440     3.11907 0.00000 0.00000
>>> 1394.82594    -399.44848      -59.25448       19.98846        2225.46440      -3.11907        0.00000 -21877.33372
>>> -21877.33372  6547.28853      971.83061       -324.87728      -36996.03248    52.60350        0.00000 -2206.49496
>>> -2206.49496   666.20014       98.97768        -33.06429       -3791.30589     5.39430 0.00000 24083.82868
>>> 24083.82868   -7213.48867     -1070.80829     357.94157       40787.33837     -57.99780       0.00000 -21953.82949
>>> -21953.82949  6578.30322      976.54971       -326.41598      -37205.87555    52.90915        0.00000 12235.00898
>>>
>>>
>>>
>>> I hope that the problem statement is clear but I am happy to answer
>>> more questions.
>>> I am looking forward to suggestions.
>>>
>>> Eryk
>>>
>>> -------------------------------------------------------------------------
>>> Using Tomcat but need to do more? Need to support web services, security?
>>> Get stuff done quickly with pre-integrated technology to make your job easier
>>> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>>> _______________________________________________
>>> sbmlsolver-devel mailing list
>>> sbm...@li...
>>> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>>>
>>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> sbmlsolver-devel mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>

Re: [SOSlib-devel] Problem with senstivities

[W E. W. <wew...@gm...>]

On 8/16/06, Rainer Machne <ra...@tb...> wrote:
> Hi Eryk,
>
> this seems to be a bug! Again, I am not in Vienna, have limited access to
> computers and can't look into the problem. It looks as if the _reset
> function doesn't reset the sensitivities to 0. I guess, this problem arose
> because events should not reset sensitivities but keep the values from
> the last time step befor the solver structures where re-initialized
> by an event.


I was looking at the reset function and it seems to be fine:

the reset function is calling I think the set function and that one is
calling the
CvodeData_initialize where the sensitivity matrix in the cvodeData_t
is set to zero.

Furthermore, what makes me think that this is not the cause of the
error is that the senstivities not only change the magnitude
(increase) but also swap the signs.
I therefor would think that the reason for the error is somewhere else.
It should be relatively easy to reproduce the error just by running
the solver in a while loop as I described and printing out the
sensitivities.


cheers




>
> Maybe you have time to look into it yourself. The function
> IntegratorInstance_reset probably calls things like CvodeData_initialize
> at it most somewhere also go into initializing the sensitivities. Both
> data->sensitivities and results->sensitivities should be set to 0 by the
> _reset function.
>
> If you don't find it yourself and maybe post the problem/solution to this
> list or even update the CVS with a solution, then I will look into it next
> week.
>
> Rainer
>
> On Tue, 15 Aug 2006, W Eryk Wolski wrote:
>
> > Hi,
> >
> > I am running the solver in a loop.
> >
> > the loop includes:
> > {
> > change of the parameters
> > running the solver
> > and a call to IntegratorInstance_reset(integratorInstance);
> > }
> >
> > What I observe and call a problem is that every new simulator run in
> > the loop generates increasing sensitivity values for the same
> > parameter values and model.
> >
> > The following output are the date stored in:
> >
> > integratorInstance->data->sensitivity
> > entries
> > integratorInstance->data->nsens, integratorInstance->data->neq
> >
> > first iteration
> >
> > parameters:  par[0] 2.000000  par[1] 8.000000  par[2] 10.000000
> > par[3] 0.100000  par[4] 2.000000
> >
> > 24.33599      -12.44311       -1.60336        0.28326 26.31235        -0.12182        0.00000 0.00000
> > -24.33599     12.44311        1.60336 -0.28326        -26.31235       0.12182 0.00000 11.93225
> > 11.93225      -4.09705        -0.54112        0.08923 8.68924 -0.04727        0.00000 -7.76276
> > -7.76276      2.05021 0.27103 -0.04458        -4.34843        0.02380 0.00000 -4.16949
> > -4.16949      2.04684 0.27009 -0.04465        -4.34081        0.02346 0.00000 -0.26712
> > -0.26712      -0.45221        -0.06041        0.00965 0.95925 -0.00565        0.00000 -1.57271
> >
> >
> > while the 10 iteration:
> >
> > -1394.82594   399.44848       59.25448        -19.98846       -2225.46440     3.11907 0.00000 0.00000
> > 1394.82594    -399.44848      -59.25448       19.98846        2225.46440      -3.11907        0.00000 -21877.33372
> > -21877.33372  6547.28853      971.83061       -324.87728      -36996.03248    52.60350        0.00000 -2206.49496
> > -2206.49496   666.20014       98.97768        -33.06429       -3791.30589     5.39430 0.00000 24083.82868
> > 24083.82868   -7213.48867     -1070.80829     357.94157       40787.33837     -57.99780       0.00000 -21953.82949
> > -21953.82949  6578.30322      976.54971       -326.41598      -37205.87555    52.90915        0.00000 12235.00898
> >
> >
> >
> > I hope that the problem statement is clear but I am happy to answer
> > more questions.
> > I am looking forward to suggestions.
> >
> > Eryk
> >
> > -------------------------------------------------------------------------
> > Using Tomcat but need to do more? Need to support web services, security?
> > Get stuff done quickly with pre-integrated technology to make your job easier
> > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> > _______________________________________________
> > sbmlsolver-devel mailing list
> > sbm...@li...
> > https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
> >
>

Re: [SOSlib-devel] Problem with senstivities

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

Hi Eryk,

this seems to be a bug! Again, I am not in Vienna, have limited access to 
computers and can't look into the problem. It looks as if the _reset 
function doesn't reset the sensitivities to 0. I guess, this problem arose 
because events should not reset sensitivities but keep the values from 
the last time step befor the solver structures where re-initialized 
by an event.

Maybe you have time to look into it yourself. The function 
IntegratorInstance_reset probably calls things like CvodeData_initialize 
at it most somewhere also go into initializing the sensitivities. Both 
data->sensitivities and results->sensitivities should be set to 0 by the 
_reset function.

If you don't find it yourself and maybe post the problem/solution to this 
list or even update the CVS with a solution, then I will look into it next 
week.

Rainer

On Tue, 15 Aug 2006, W Eryk Wolski wrote:

> Hi,
>
> I am running the solver in a loop.
>
> the loop includes:
> {
> change of the parameters
> running the solver
> and a call to IntegratorInstance_reset(integratorInstance);
> }
>
> What I observe and call a problem is that every new simulator run in
> the loop generates increasing sensitivity values for the same
> parameter values and model.
>
> The following output are the date stored in:
>
> integratorInstance->data->sensitivity
> entries
> integratorInstance->data->nsens, integratorInstance->data->neq
>
> first iteration
>
> parameters:  par[0] 2.000000  par[1] 8.000000  par[2] 10.000000
> par[3] 0.100000  par[4] 2.000000
>
> 24.33599	-12.44311	-1.60336	0.28326	26.31235	-0.12182	0.00000	0.00000
> -24.33599	12.44311	1.60336	-0.28326	-26.31235	0.12182	0.00000	11.93225
> 11.93225	-4.09705	-0.54112	0.08923	8.68924	-0.04727	0.00000	-7.76276
> -7.76276	2.05021	0.27103	-0.04458	-4.34843	0.02380	0.00000	-4.16949
> -4.16949	2.04684	0.27009	-0.04465	-4.34081	0.02346	0.00000	-0.26712
> -0.26712	-0.45221	-0.06041	0.00965	0.95925	-0.00565	0.00000	-1.57271
>
>
> while the 10 iteration:
>
> -1394.82594	399.44848	59.25448	-19.98846	-2225.46440	3.11907	0.00000	0.00000
> 1394.82594	-399.44848	-59.25448	19.98846	2225.46440	-3.11907	0.00000	-21877.33372
> -21877.33372	6547.28853	971.83061	-324.87728	-36996.03248	52.60350	0.00000	-2206.49496
> -2206.49496	666.20014	98.97768	-33.06429	-3791.30589	5.39430	0.00000	24083.82868
> 24083.82868	-7213.48867	-1070.80829	357.94157	40787.33837	-57.99780	0.00000	-21953.82949
> -21953.82949	6578.30322	976.54971	-326.41598	-37205.87555	52.90915	0.00000	12235.00898
>
>
>
> I hope that the problem statement is clear but I am happy to answer
> more questions.
> I am looking forward to suggestions.
>
> Eryk
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> sbmlsolver-devel mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>

[SOSlib-devel] Problem with senstivities

[W E. W. <wew...@gm...>]

Hi,

I am running the solver in a loop.

the loop includes:
{
change of the parameters
running the solver
and a call to IntegratorInstance_reset(integratorInstance);
}

What I observe and call a problem is that every new simulator run in
the loop generates increasing sensitivity values for the same
parameter values and model.

The following output are the date stored in:

integratorInstance->data->sensitivity
entries
integratorInstance->data->nsens, integratorInstance->data->neq

first iteration

parameters:  par[0] 2.000000  par[1] 8.000000  par[2] 10.000000
par[3] 0.100000  par[4] 2.000000

24.33599	-12.44311	-1.60336	0.28326	26.31235	-0.12182	0.00000	0.00000	
-24.33599	12.44311	1.60336	-0.28326	-26.31235	0.12182	0.00000	11.93225	
11.93225	-4.09705	-0.54112	0.08923	8.68924	-0.04727	0.00000	-7.76276	
-7.76276	2.05021	0.27103	-0.04458	-4.34843	0.02380	0.00000	-4.16949	
-4.16949	2.04684	0.27009	-0.04465	-4.34081	0.02346	0.00000	-0.26712	
-0.26712	-0.45221	-0.06041	0.00965	0.95925	-0.00565	0.00000	-1.57271	


while the 10 iteration:

-1394.82594	399.44848	59.25448	-19.98846	-2225.46440	3.11907	0.00000	0.00000	
1394.82594	-399.44848	-59.25448	19.98846	2225.46440	-3.11907	0.00000	-21877.33372
-21877.33372	6547.28853	971.83061	-324.87728	-36996.03248	52.60350	0.00000	-2206.49496
-2206.49496	666.20014	98.97768	-33.06429	-3791.30589	5.39430	0.00000	24083.82868
24083.82868	-7213.48867	-1070.80829	357.94157	40787.33837	-57.99780	0.00000	-21953.82949
-21953.82949	6578.30322	976.54971	-326.41598	-37205.87555	52.90915	0.00000	12235.00898



I hope that the problem statement is clear but I am happy to answer
more questions.
I am looking forward to suggestions.

Eryk

Re: [SOSlib-devel] nvalues

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

And one more important thing:

The reason to keep the names and values array separated is mainly to make 
it possible to run multiple integrations, i.e. different values, with one 
odeModel. I.e. you can create as many integratorInstance_t structures from 
one odeModel_t as you like.

And again, the main interface to the names and values is the 
structure variableIndex_t.

See the get/set functions for the integratorInstance_t
http://www.tbi.univie.ac.at/~raim/odeSolver/doc/api/group__integrator.html#ga10

and for the odeModel_t at
http://www.tbi.univie.ac.at/~raim/odeSolver/doc/api/group__variableIndex.html

Rainer


On Mon, 7 Aug 2006, Rainer Machne wrote:

>
> Hi Eryk,
>
> I know the nvalues array can be confusing. The main problem is that
> keeping all values of the model, i.e. current values of variables (ODE and
> assignment equations) and parameters in ONE array makes a lot of things,
> such as formula evaluation and setting of the values via interface
> functions, much easier.
>
>> Question? What is the length of the names array?
>
> The arrays "names" in odeModel_t and "values" in cvodeData_t and
> cvodeResults_t correspond to each other. They have the same length
> "nvalues".
>
> The neq, nalg (currently always == 0), nass and nconst are offsets in
> these arrays.
>
> Note that,
>  nvalues = neq + nalg + nass + nconst;
>
>> What are the indices of the species please?
>
> It is important to realize that SBML species have no unique mapping to the
> odeModel_t.
>
> If they are defined by an ODE their name and value is found in
> odeModel->names[i] and
> cvodeData->values[i], respectively,
> where i is from 0 to (neq-1)
>
> If they are defined by an assignment rule i is from neq to (neq+nass -1),
> and if they are constant (including constants changed by an event) i is
> from (neq+nass) to (neq+nass+nvalues -1).
>
>> How to determine the indices of the x(t), etc??
>
> As said above cvodeData->values[i] is the value of the
> variable or parameter in odeModel->names[i].
>
> If you want the current value of an object of the SBML model, you can also
> use the variableIndex_t via the functions:
>
> variableIndex_t *ODEModel_getVariableIndex (odeModel_t *om, const char *symbol)
> where "symbol" is the SBML ID of this object.
>
> Then you can use
>
> double 	IntegratorInstance_getVariableValue (integratorInstance_t *engine,
> variableIndex_t *vi)
>
> to get the value of this object or use
>
> void 	IntegratorInstance_setVariableValue (integratorInstance_t *engine,
> variableIndex_t *vi, double value)
>
> to set the object to the passed double value.
>
> Did this make it any clearer??
>
> Rainer
>
>
> On Tue, 1 Aug 2006, W Eryk Wolski wrote:
>
>> Hi,
>>
>> An old questions revisited?
>>
>> in definition of structure odeModel,
>>
>>    /** All names, i.e. ODE variables, assigned parameters, and constant
>> 	parameters */
>>    char **names;
>>
>>    int neq;    /**< number of ODEs */
>>    int nalg;   /**< number of algebraic rules */
>>    int nass;   /**< number of assigned variables (nass) */
>>    int nconst; /**< number of constant parameters */
>>
>> Question? What is the length of the names array?
>>
>>
>> In definition of structure cvodeResults
>>
>>  /** number of variables for which results exist */
>>  int nvalues;
>>  /** the following arrays represent the time series of all variables
>>      and parameters of the model */
>>  double **value;
>>
>> Question:
>> What are the indices of the species please?
>>
>>
>> In defintion of structure cvodeData
>>
>> /** total number of values (variables x(t) + parameters p) */
>>  int nvalues;
>>  /** value array is used to write and read the current values of
>>      all variables x(t) and parameters p of the system (of which
>>      there are `nvalues') */
>>  double *value;
>>
>> How to determine the indices of the x(t), etc??
>>
>>
>> For me this issue is confusing since I have started to play arround
>> with soslib.
>>
>> Eryk
>>
>> -------------------------------------------------------------------------
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to share your
>> opinions on IT & business topics through brief surveys -- and earn cash
>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>> _______________________________________________
>> sbmlsolver-devel mailing list
>> sbm...@li...
>> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> sbmlsolver-devel mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>

Re: [SOSlib-devel] nvalues

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

Hi Eryk,

I know the nvalues array can be confusing. The main problem is that 
keeping all values of the model, i.e. current values of variables (ODE and 
assignment equations) and parameters in ONE array makes a lot of things, 
such as formula evaluation and setting of the values via interface 
functions, much easier.

> Question? What is the length of the names array?

The arrays "names" in odeModel_t and "values" in cvodeData_t and 
cvodeResults_t correspond to each other. They have the same length 
"nvalues".

The neq, nalg (currently always == 0), nass and nconst are offsets in 
these arrays.

Note that,
  nvalues = neq + nalg + nass + nconst;

> What are the indices of the species please?

It is important to realize that SBML species have no unique mapping to the 
odeModel_t.

If they are defined by an ODE their name and value is found in
odeModel->names[i] and
cvodeData->values[i], respectively,
where i is from 0 to (neq-1)

If they are defined by an assignment rule i is from neq to (neq+nass -1), 
and if they are constant (including constants changed by an event) i is 
from (neq+nass) to (neq+nass+nvalues -1).

> How to determine the indices of the x(t), etc??

As said above cvodeData->values[i] is the value of the 
variable or parameter in odeModel->names[i].

If you want the current value of an object of the SBML model, you can also 
use the variableIndex_t via the functions:

variableIndex_t *ODEModel_getVariableIndex (odeModel_t *om, const char *symbol)
where "symbol" is the SBML ID of this object.

Then you can use

double 	IntegratorInstance_getVariableValue (integratorInstance_t *engine, 
variableIndex_t *vi)

to get the value of this object or use

void 	IntegratorInstance_setVariableValue (integratorInstance_t *engine, 
variableIndex_t *vi, double value)

to set the object to the passed double value.

Did this make it any clearer??

Rainer


On Tue, 1 Aug 2006, W Eryk Wolski wrote:

> Hi,
>
> An old questions revisited?
>
> in definition of structure odeModel,
>
>    /** All names, i.e. ODE variables, assigned parameters, and constant
> 	parameters */
>    char **names;
>
>    int neq;    /**< number of ODEs */
>    int nalg;   /**< number of algebraic rules */
>    int nass;   /**< number of assigned variables (nass) */
>    int nconst; /**< number of constant parameters */
>
> Question? What is the length of the names array?
>
>
> In definition of structure cvodeResults
>
>  /** number of variables for which results exist */
>  int nvalues;
>  /** the following arrays represent the time series of all variables
>      and parameters of the model */
>  double **value;
>
> Question:
> What are the indices of the species please?
>
>
> In defintion of structure cvodeData
>
> /** total number of values (variables x(t) + parameters p) */
>  int nvalues;
>  /** value array is used to write and read the current values of
>      all variables x(t) and parameters p of the system (of which
>      there are `nvalues') */
>  double *value;
>
> How to determine the indices of the x(t), etc??
>
>
> For me this issue is confusing since I have started to play arround
> with soslib.
>
> Eryk
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> sbmlsolver-devel mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>

Re: [SOSlib-devel] convergence failed repeatedly[Scanned]

[Andrew F. <af...@ph...>]

Eryk

What API functions are you calling?

Are you calling

SolverError_getNum

between calls to the API
or using the macros:

RETURN_ON_ERRORS_WITH

or=20

RETURN_ON_FATALS_WITH

see solverError.h

Andrew=20

> -----Original Message-----
> From: sbm...@li...=20
> [mailto:sbm...@li...] On=20
> Behalf Of W Eryk Wolski
> Sent: 02 August 2006 15:42
> To: sbm...@li...
> Subject: [SOSlib-devel] convergence failed repeatedly[Scanned]
>=20
> Hi,
>=20
>=20
> Is there a way to "catch" the following error and to avoid a=20
> core dump?
>=20
>=20
> CVode-- At t =3D 158.061 and h =3D 3.02215e-05, the corrector=20
> convergence failed repeatedly or with |h| =3D hmin.
>=20
> Segmentation fault (core dumped)
>=20
>=20
> Thanks
> Eryk
>=20
> --------------------------------------------------------------
> -----------
> Take Surveys. Earn Cash. Influence the Future of IT Join=20
> SourceForge.net's Techsay panel and you'll get the chance to=20
> share your opinions on IT & business topics through brief=20
> surveys -- and earn cash=20
> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge
> &CID=3DDEVDEV
> _______________________________________________
> sbmlsolver-devel mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>=20

Re: [SOSlib-devel] convergence failed repeatedly[Scanned]

[Andrew F. <af...@ph...>]

Eryk

That's a bug.  It shouldn't crash like that.

Are you sure the crash is in soslib?=20

Can you send the source code positions of all the
functions on the stack at the point of the crash?

Andrew

> -----Original Message-----
> From: sbm...@li...=20
> [mailto:sbm...@li...] On=20
> Behalf Of W Eryk Wolski
> Sent: 02 August 2006 15:42
> To: sbm...@li...
> Subject: [SOSlib-devel] convergence failed repeatedly[Scanned]
>=20
> Hi,
>=20
>=20
> Is there a way to "catch" the following error and to avoid a=20
> core dump?
>=20
>=20
> CVode-- At t =3D 158.061 and h =3D 3.02215e-05, the corrector=20
> convergence failed repeatedly or with |h| =3D hmin.
>=20
> Segmentation fault (core dumped)
>=20
>=20
> Thanks
> Eryk
>=20
> --------------------------------------------------------------
> -----------
> Take Surveys. Earn Cash. Influence the Future of IT Join=20
> SourceForge.net's Techsay panel and you'll get the chance to=20
> share your opinions on IT & business topics through brief=20
> surveys -- and earn cash=20
> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge
> &CID=3DDEVDEV
> _______________________________________________
> sbmlsolver-devel mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>=20

[SOSlib-devel] convergence failed repeatedly

[W E. W. <wew...@gm...>]

Hi,


Is there a way to "catch" the following error and to avoid a core dump?


CVode-- At t = 158.061 and h = 3.02215e-05, the corrector
convergence failed repeatedly or with |h| = hmin.

Segmentation fault (core dumped)


Thanks
Eryk

[SOSlib-devel] nvalues

[W E. W. <wew...@gm...>]

Hi,

An old questions revisited?

in definition of structure odeModel,

    /** All names, i.e. ODE variables, assigned parameters, and constant
	parameters */
    char **names;

    int neq;    /**< number of ODEs */
    int nalg;   /**< number of algebraic rules */
    int nass;   /**< number of assigned variables (nass) */
    int nconst; /**< number of constant parameters */

Question? What is the length of the names array?


In definition of structure cvodeResults

  /** number of variables for which results exist */
  int nvalues;
  /** the following arrays represent the time series of all variables
      and parameters of the model */
  double **value;

Question:
What are the indices of the species please?


In defintion of structure cvodeData

/** total number of values (variables x(t) + parameters p) */
  int nvalues;
  /** value array is used to write and read the current values of
      all variables x(t) and parameters p of the system (of which
      there are `nvalues') */
  double *value;

How to determine the indices of the x(t), etc??


For me this issue is confusing since I have started to play arround
with soslib.

Eryk

Re: [SOSlib-devel] code for dynamic compilation on UNIX

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

Hi Andrew

I get an error for PATH_MAX. Where is this defined?

R


On Wed, 19 Jul 2006, Andrew Finney wrote:

> Folks
>
> I've attached the code I used for UNIX dynamic compilation.
> I suggest you remove the /usr/bin/gcc with just gcc
>
> Have fun
>
> Andrew
>

Re: [SOSlib-devel] code for dynamic compilation on UNIX

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

you're my hero :) looking forward to try this out!

On Wed, 19 Jul 2006, Andrew Finney wrote:

> Folks
>
> I've attached the code I used for UNIX dynamic compilation.
> I suggest you remove the /usr/bin/gcc with just gcc
>
> Have fun
>
> Andrew
>

[SOSlib-devel] spurious comments

[Andrew F. <af...@ph...>]

Folks

Please remove the references to tcc in the header file I just sent with
respect to UNIX as that's not how it works!

yours Andrew

[SOSlib-devel] code for dynamic compilation on UNIX

[Andrew F. <af...@ph...>]

Folks

I've attached the code I used for UNIX dynamic compilation.
I suggest you remove the /usr/bin/gcc with just gcc

Have fun

Andrew

[SOSlib-devel] CVS update: commandline switch for integration method

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

Hi

in the commandline tool (odeSolver, SBML_odeSolverApp.exe) it is now 
possible to switch between integration methods (adams-moulton, backward 
differentiation formula) and iteration methods (functional, newton) with 
the arguments --method 0/1 and --iteration 0/1. Default values are 0 for 
BDF and Newton methods, as before. Note, that any values other than 1 will 
lead to default methods.

Rainer

Re: [SOSlib-devel] Compilation errors on Kubuntu linux.[Scanned]

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

i have added this to the wiki.


On Mon, 17 Jul 2006, Andrew Finney wrote:

> Folks
>
> Ideally the configure scripts should work this out - but I'm not
> volunteering :-)
>
> yours
>
> Andrew
>
>> -----Original Message-----
>> From: sbm...@li...
>> [mailto:sbm...@li...] On
>> Behalf Of Rainer Machne
>> Sent: 17 July 2006 10:43
>> To: W Eryk Wolski
>> Cc: sbm...@li...
>> Subject: Re: [SOSlib-devel] Compilation errors on Kubuntu
>> linux.[Scanned]
>>
>> Hi Eryk,
>>
>> acosh, asinh and atanh are defined in tgmath.h, which
>> provides some additional functions to the ones in math.
>>
>> However, it wasn't availalbe on some platforms so Andrew (i
>> think) included these functions within WIN32 tags but i
>> removed those tags because of a general ISO C90
>> incompatibility of tgmath.h (and SOSlib wants to be ISO C90).
>>
>> Maybe your math.h includes the tgmath.h ?
>> I think that was the reason why it initally worked here on
>> our machines without either those local declarations or
>> including tgmath.h
>>
>> Anyways, you can try to remove the static function
>> definitions for acsoh, asinh and atanh from your local copy
>> of processAST.c and rely on your local definitions (should be
>> OK!) or check whether the math.h on your system includes
>> tgmath.h and use another version of math.h
>>
>> I am not so familiar with all that ISO C stuff. So maybe
>> someone else can give a more detailed answer.
>>
>> Maybe we need to add some tags like
>> #ifdef acosh
>> etc. around these function declarations?
>>
>> Rainer
>>
>>
>>
>>
>>
>>
>> On Thu, 13 Jul 2006, W Eryk Wolski wrote:
>>
>>> Dear all,
>>>
>>> Getting compilation errors on Kubuntu 6.0.6 with gcc 4.0.3
>>>
>>>
>>>
>>>        then mv -f ".deps/odeConstruct.Tpo" ".deps/odeConstruct.Po";
>>> else rm -f ".deps/odeConstruct.Tpo"; exit 1; fi if gcc
>> -DHAVE_CONFIG_H
>>> -I. -I. -I../src/sbmlsolver -I/home/witek/opt/sundials/include
>>> -I/home/witek/opt/libsbml2.3.4/include
>>> -I/home/witek/opt/libsbml2.3.4/include/sbml
>>> -I/home/witek/opt/libsbml2.3.4/include
>>> -I/home/witek/opt/libsbml2.3.4/include/sbml/sbml -I.     -MT
>>> odeModel.o -MD -MP -MF ".deps/odeModel.Tpo" -c -o odeModel.o
>>> odeModel.c; \
>>>        then mv -f ".deps/odeModel.Tpo" ".deps/odeModel.Po";
>> else rm -f
>>> ".deps/odeModel.Tpo"; exit 1; fi
>>> odeModel.c: In function 'ODEModel_computeAssignmentRuleSets':
>>> odeModel.c:417: warning: passing argument 1 of 'ASTNode_getSymbols'
>>> discards qualifiers from pointer target type
>>> odeModel.c:424: warning: passing argument 1 of 'ASTNode_getSymbols'
>>> discards qualifiers from pointer target type
>>> odeModel.c:426: warning: passing argument 2 of 'List_add' discards
>>> qualifiers from pointer target type
>>> odeModel.c: In function 'ODEModel_createFromFileWithObservables':
>>> odeModel.c:744: warning: passing argument 1 of 'parseModel'
>> discards
>>> qualifiers from pointer target type if gcc -DHAVE_CONFIG_H -I. -I.
>>> -I../src/sbmlsolver -I/home/witek/opt/sundials/include
>>> -I/home/witek/opt/libsbml2.3.4/include
>>> -I/home/witek/opt/libsbml2.3.4/include/sbml
>>> -I/home/witek/opt/libsbml2.3.4/include
>>> -I/home/witek/opt/libsbml2.3.4/include/sbml/sbml -I.     -MT
>>> odeSolver.o -MD -MP -MF ".deps/odeSolver.Tpo" -c -o odeSolver.o
>>> odeSolver.c; \
>>>        then mv -f ".deps/odeSolver.Tpo"
>> ".deps/odeSolver.Po"; else rm
>>> -f ".deps/odeSolver.Tpo"; exit 1; fi if gcc -DHAVE_CONFIG_H -I. -I.
>>> -I../src/sbmlsolver -I/home/witek/opt/sundials/include
>>> -I/home/witek/opt/libsbml2.3.4/include
>>> -I/home/witek/opt/libsbml2.3.4/include/sbml
>>> -I/home/witek/opt/libsbml2.3.4/include
>>> -I/home/witek/opt/libsbml2.3.4/include/sbml/sbml -I.     -MT
>>> processAST.o -MD -MP -MF ".deps/processAST.Tpo" -c -o processAST.o
>>> processAST.c; \
>>>        then mv -f ".deps/processAST.Tpo"
>> ".deps/processAST.Po"; else
>>> rm -f ".deps/processAST.Tpo"; exit 1; fi
>>> processAST.c:69: error: static declaration of 'acosh' follows
>>> non-static declaration
>>> processAST.c:74: error: static declaration of 'asinh' follows
>>> non-static declaration
>>> processAST.c:79: error: static declaration of 'atanh' follows
>>> non-static declaration
>>> make[1]: *** [processAST.o] Error 1
>>> make[1]: Leaving directory
>>> `/home/witek/devel/cpp/odesolver/sos3/SBML_odeSolver/src'
>>> make: *** [all-recursive] Error 1
>>>
>>>
>>> Any suggestions
>>>
>>> Eryk
>>>
>>>
>>>
>> ----------------------------------------------------------------------
>>> --- Using Tomcat but need to do more? Need to support web services,
>>> security?
>>> Get stuff done quickly with pre-integrated technology to
>> make your job
>>> easier Download IBM WebSphere Application Server v.1.0.1 based on
>>> Apache Geronimo
>>>
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=1216
>>> 42 _______________________________________________
>>> sbmlsolver-devel mailing list
>>> sbm...@li...
>>> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>>>
>>
>>
>> --------------------------------------------------------------
>> -----------
>> Using Tomcat but need to do more? Need to support web
>> services, security?
>> Get stuff done quickly with pre-integrated technology to make
>> your job easier Download IBM WebSphere Application Server
>> v.1.0.1 based on Apache Geronimo
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&
>> dat=121642
>> _______________________________________________
>> sbmlsolver-devel mailing list
>> sbm...@li...
>> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>>
>

Re: [SOSlib-devel] Compilation errors on Kubuntu linux.[Scanned]

[Andrew F. <af...@ph...>]

Folks

Ideally the configure scripts should work this out - but I'm not
volunteering :-)

yours

Andrew=20

> -----Original Message-----
> From: sbm...@li...=20
> [mailto:sbm...@li...] On=20
> Behalf Of Rainer Machne
> Sent: 17 July 2006 10:43
> To: W Eryk Wolski
> Cc: sbm...@li...
> Subject: Re: [SOSlib-devel] Compilation errors on Kubuntu=20
> linux.[Scanned]
>=20
> Hi Eryk,
>=20
> acosh, asinh and atanh are defined in tgmath.h, which=20
> provides some additional functions to the ones in math.
>=20
> However, it wasn't availalbe on some platforms so Andrew (i=20
> think) included these functions within WIN32 tags but i=20
> removed those tags because of a general ISO C90=20
> incompatibility of tgmath.h (and SOSlib wants to be ISO C90).
>=20
> Maybe your math.h includes the tgmath.h ?
> I think that was the reason why it initally worked here on=20
> our machines without either those local declarations or=20
> including tgmath.h
>=20
> Anyways, you can try to remove the static function=20
> definitions for acsoh, asinh and atanh from your local copy=20
> of processAST.c and rely on your local definitions (should be=20
> OK!) or check whether the math.h on your system includes=20
> tgmath.h and use another version of math.h
>=20
> I am not so familiar with all that ISO C stuff. So maybe=20
> someone else can give a more detailed answer.
>=20
> Maybe we need to add some tags like
> #ifdef acosh
> etc. around these function declarations?
>=20
> Rainer
>=20
>=20
>=20
>=20
>=20
>=20
> On Thu, 13 Jul 2006, W Eryk Wolski wrote:
>=20
> > Dear all,
> >
> > Getting compilation errors on Kubuntu 6.0.6 with gcc 4.0.3
> >
> >
> >
> >        then mv -f ".deps/odeConstruct.Tpo" ".deps/odeConstruct.Po";=20
> > else rm -f ".deps/odeConstruct.Tpo"; exit 1; fi if gcc=20
> -DHAVE_CONFIG_H=20
> > -I. -I. -I../src/sbmlsolver -I/home/witek/opt/sundials/include
> > -I/home/witek/opt/libsbml2.3.4/include
> > -I/home/witek/opt/libsbml2.3.4/include/sbml
> > -I/home/witek/opt/libsbml2.3.4/include
> > -I/home/witek/opt/libsbml2.3.4/include/sbml/sbml -I.     -MT
> > odeModel.o -MD -MP -MF ".deps/odeModel.Tpo" -c -o odeModel.o=20
> > odeModel.c; \
> >        then mv -f ".deps/odeModel.Tpo" ".deps/odeModel.Po";=20
> else rm -f=20
> > ".deps/odeModel.Tpo"; exit 1; fi
> > odeModel.c: In function 'ODEModel_computeAssignmentRuleSets':
> > odeModel.c:417: warning: passing argument 1 of 'ASTNode_getSymbols'
> > discards qualifiers from pointer target type
> > odeModel.c:424: warning: passing argument 1 of 'ASTNode_getSymbols'
> > discards qualifiers from pointer target type
> > odeModel.c:426: warning: passing argument 2 of 'List_add' discards=20
> > qualifiers from pointer target type
> > odeModel.c: In function 'ODEModel_createFromFileWithObservables':
> > odeModel.c:744: warning: passing argument 1 of 'parseModel'=20
> discards=20
> > qualifiers from pointer target type if gcc -DHAVE_CONFIG_H -I. -I.=20
> > -I../src/sbmlsolver -I/home/witek/opt/sundials/include
> > -I/home/witek/opt/libsbml2.3.4/include
> > -I/home/witek/opt/libsbml2.3.4/include/sbml
> > -I/home/witek/opt/libsbml2.3.4/include
> > -I/home/witek/opt/libsbml2.3.4/include/sbml/sbml -I.     -MT
> > odeSolver.o -MD -MP -MF ".deps/odeSolver.Tpo" -c -o odeSolver.o=20
> > odeSolver.c; \
> >        then mv -f ".deps/odeSolver.Tpo"=20
> ".deps/odeSolver.Po"; else rm=20
> > -f ".deps/odeSolver.Tpo"; exit 1; fi if gcc -DHAVE_CONFIG_H -I. -I.=20
> > -I../src/sbmlsolver -I/home/witek/opt/sundials/include
> > -I/home/witek/opt/libsbml2.3.4/include
> > -I/home/witek/opt/libsbml2.3.4/include/sbml
> > -I/home/witek/opt/libsbml2.3.4/include
> > -I/home/witek/opt/libsbml2.3.4/include/sbml/sbml -I.     -MT
> > processAST.o -MD -MP -MF ".deps/processAST.Tpo" -c -o processAST.o=20
> > processAST.c; \
> >        then mv -f ".deps/processAST.Tpo"=20
> ".deps/processAST.Po"; else=20
> > rm -f ".deps/processAST.Tpo"; exit 1; fi
> > processAST.c:69: error: static declaration of 'acosh' follows=20
> > non-static declaration
> > processAST.c:74: error: static declaration of 'asinh' follows=20
> > non-static declaration
> > processAST.c:79: error: static declaration of 'atanh' follows=20
> > non-static declaration
> > make[1]: *** [processAST.o] Error 1
> > make[1]: Leaving directory
> > `/home/witek/devel/cpp/odesolver/sos3/SBML_odeSolver/src'
> > make: *** [all-recursive] Error 1
> >
> >
> > Any suggestions
> >
> > Eryk
> >
> >
> >=20
> ----------------------------------------------------------------------
> > --- Using Tomcat but need to do more? Need to support web services,=20
> > security?
> > Get stuff done quickly with pre-integrated technology to=20
> make your job=20
> > easier Download IBM WebSphere Application Server v.1.0.1 based on=20
> > Apache Geronimo
> >=20
> =
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D=
1216
> > 42 _______________________________________________
> > sbmlsolver-devel mailing list
> > sbm...@li...
> > https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
> >
>=20
>=20
> --------------------------------------------------------------
> -----------
> Using Tomcat but need to do more? Need to support web=20
> services, security?
> Get stuff done quickly with pre-integrated technology to make=20
> your job easier Download IBM WebSphere Application Server=20
> v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&
> dat=3D121642
> _______________________________________________
> sbmlsolver-devel mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>=20

Re: [SOSlib-devel] Compilation errors on Kubuntu linux.

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

Hi Eryk,

acosh, asinh and atanh are defined in tgmath.h,
which provides some additional functions to the ones in math.

However, it wasn't availalbe on some platforms so Andrew (i think)
included these functions within WIN32 tags but i removed those 
tags because of a general ISO C90 incompatibility of tgmath.h
(and SOSlib wants to be ISO C90).

Maybe your math.h includes the tgmath.h ?
I think that was the reason why it initally worked here on our machines 
without either those local declarations or including tgmath.h

Anyways, you can try to remove the static function definitions for acsoh,
asinh and atanh from your local copy of processAST.c and rely on your 
local definitions (should be OK!) or check whether the math.h on your 
system includes tgmath.h and use another version of math.h

I am not so familiar with all that ISO C stuff. So maybe someone else can 
give a more detailed answer.

Maybe we need to add some tags like
#ifdef acosh
etc. around these function declarations?

Rainer






On Thu, 13 Jul 2006, W Eryk Wolski wrote:

> Dear all,
>
> Getting compilation errors on Kubuntu 6.0.6 with gcc 4.0.3
>
>
>
>        then mv -f ".deps/odeConstruct.Tpo" ".deps/odeConstruct.Po";
> else rm -f ".deps/odeConstruct.Tpo"; exit 1; fi
> if gcc -DHAVE_CONFIG_H -I. -I. -I../src/sbmlsolver
> -I/home/witek/opt/sundials/include
> -I/home/witek/opt/libsbml2.3.4/include
> -I/home/witek/opt/libsbml2.3.4/include/sbml
> -I/home/witek/opt/libsbml2.3.4/include
> -I/home/witek/opt/libsbml2.3.4/include/sbml/sbml -I.     -MT
> odeModel.o -MD -MP -MF ".deps/odeModel.Tpo" -c -o odeModel.o
> odeModel.c; \
>        then mv -f ".deps/odeModel.Tpo" ".deps/odeModel.Po"; else rm
> -f ".deps/odeModel.Tpo"; exit 1; fi
> odeModel.c: In function 'ODEModel_computeAssignmentRuleSets':
> odeModel.c:417: warning: passing argument 1 of 'ASTNode_getSymbols'
> discards qualifiers from pointer target type
> odeModel.c:424: warning: passing argument 1 of 'ASTNode_getSymbols'
> discards qualifiers from pointer target type
> odeModel.c:426: warning: passing argument 2 of 'List_add' discards
> qualifiers from pointer target type
> odeModel.c: In function 'ODEModel_createFromFileWithObservables':
> odeModel.c:744: warning: passing argument 1 of 'parseModel' discards
> qualifiers from pointer target type
> if gcc -DHAVE_CONFIG_H -I. -I. -I../src/sbmlsolver
> -I/home/witek/opt/sundials/include
> -I/home/witek/opt/libsbml2.3.4/include
> -I/home/witek/opt/libsbml2.3.4/include/sbml
> -I/home/witek/opt/libsbml2.3.4/include
> -I/home/witek/opt/libsbml2.3.4/include/sbml/sbml -I.     -MT
> odeSolver.o -MD -MP -MF ".deps/odeSolver.Tpo" -c -o odeSolver.o
> odeSolver.c; \
>        then mv -f ".deps/odeSolver.Tpo" ".deps/odeSolver.Po"; else rm
> -f ".deps/odeSolver.Tpo"; exit 1; fi
> if gcc -DHAVE_CONFIG_H -I. -I. -I../src/sbmlsolver
> -I/home/witek/opt/sundials/include
> -I/home/witek/opt/libsbml2.3.4/include
> -I/home/witek/opt/libsbml2.3.4/include/sbml
> -I/home/witek/opt/libsbml2.3.4/include
> -I/home/witek/opt/libsbml2.3.4/include/sbml/sbml -I.     -MT
> processAST.o -MD -MP -MF ".deps/processAST.Tpo" -c -o processAST.o
> processAST.c; \
>        then mv -f ".deps/processAST.Tpo" ".deps/processAST.Po"; else
> rm -f ".deps/processAST.Tpo"; exit 1; fi
> processAST.c:69: error: static declaration of 'acosh' follows
> non-static declaration
> processAST.c:74: error: static declaration of 'asinh' follows
> non-static declaration
> processAST.c:79: error: static declaration of 'atanh' follows
> non-static declaration
> make[1]: *** [processAST.o] Error 1
> make[1]: Leaving directory
> `/home/witek/devel/cpp/odesolver/sos3/SBML_odeSolver/src'
> make: *** [all-recursive] Error 1
>
>
> Any suggestions
>
> Eryk
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> sbmlsolver-devel mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>

[SOSlib-devel] Compilation errors on Kubuntu linux.

[W E. W. <wew...@gm...>]

Dear all,

Getting compilation errors on Kubuntu 6.0.6 with gcc 4.0.3



        then mv -f ".deps/odeConstruct.Tpo" ".deps/odeConstruct.Po";
else rm -f ".deps/odeConstruct.Tpo"; exit 1; fi
if gcc -DHAVE_CONFIG_H -I. -I. -I../src/sbmlsolver
-I/home/witek/opt/sundials/include
-I/home/witek/opt/libsbml2.3.4/include
-I/home/witek/opt/libsbml2.3.4/include/sbml
-I/home/witek/opt/libsbml2.3.4/include
-I/home/witek/opt/libsbml2.3.4/include/sbml/sbml -I.     -MT
odeModel.o -MD -MP -MF ".deps/odeModel.Tpo" -c -o odeModel.o
odeModel.c; \
        then mv -f ".deps/odeModel.Tpo" ".deps/odeModel.Po"; else rm
-f ".deps/odeModel.Tpo"; exit 1; fi
odeModel.c: In function 'ODEModel_computeAssignmentRuleSets':
odeModel.c:417: warning: passing argument 1 of 'ASTNode_getSymbols'
discards qualifiers from pointer target type
odeModel.c:424: warning: passing argument 1 of 'ASTNode_getSymbols'
discards qualifiers from pointer target type
odeModel.c:426: warning: passing argument 2 of 'List_add' discards
qualifiers from pointer target type
odeModel.c: In function 'ODEModel_createFromFileWithObservables':
odeModel.c:744: warning: passing argument 1 of 'parseModel' discards
qualifiers from pointer target type
if gcc -DHAVE_CONFIG_H -I. -I. -I../src/sbmlsolver
-I/home/witek/opt/sundials/include
-I/home/witek/opt/libsbml2.3.4/include
-I/home/witek/opt/libsbml2.3.4/include/sbml
-I/home/witek/opt/libsbml2.3.4/include
-I/home/witek/opt/libsbml2.3.4/include/sbml/sbml -I.     -MT
odeSolver.o -MD -MP -MF ".deps/odeSolver.Tpo" -c -o odeSolver.o
odeSolver.c; \
        then mv -f ".deps/odeSolver.Tpo" ".deps/odeSolver.Po"; else rm
-f ".deps/odeSolver.Tpo"; exit 1; fi
if gcc -DHAVE_CONFIG_H -I. -I. -I../src/sbmlsolver
-I/home/witek/opt/sundials/include
-I/home/witek/opt/libsbml2.3.4/include
-I/home/witek/opt/libsbml2.3.4/include/sbml
-I/home/witek/opt/libsbml2.3.4/include
-I/home/witek/opt/libsbml2.3.4/include/sbml/sbml -I.     -MT
processAST.o -MD -MP -MF ".deps/processAST.Tpo" -c -o processAST.o
processAST.c; \
        then mv -f ".deps/processAST.Tpo" ".deps/processAST.Po"; else
rm -f ".deps/processAST.Tpo"; exit 1; fi
processAST.c:69: error: static declaration of 'acosh' follows
non-static declaration
processAST.c:74: error: static declaration of 'asinh' follows
non-static declaration
processAST.c:79: error: static declaration of 'atanh' follows
non-static declaration
make[1]: *** [processAST.o] Error 1
make[1]: Leaving directory
`/home/witek/devel/cpp/odesolver/sos3/SBML_odeSolver/src'
make: *** [all-recursive] Error 1


Any suggestions

Eryk

Re: [SOSlib-devel] spatial dimension zero[Scanned]

[Andrew F. <af...@ph...>]

Rainer

you wrote:

> Is the stochastic test suite with such models available yet?

yes.  I'm pretty sure Darren Wilkinson announced it on sbml-discuss

yours Andrew=20

> -----Original Message-----
> From: Rainer Machne [mailto:ra...@tb...]=20
> Sent: 26 June 2006 11:56
> To: Andrew Finney
> Cc: SOSlib Development
> Subject: Re: [SOSlib-devel] spatial dimension zero[Scanned]
>=20
>=20
>=20
> >> can a compartment of dimension zero have a size?
> >
> > No
> >
> >>
> >> would we currently handle such structures correctly, at least for=20
> >> fixed compartment sizes?
> >
> > I don't see why not
>=20
> Mhm, I guess we might get an error for Compartment_getValue,=20
> because at the moment I think we treat all compartments as a=20
> constant having a size.=20
> E.g. all ODEs are automatically divided by the compartment size.
>=20
> Is the stochastic test suite with such models available yet?
>=20
> Rainer
>=20
>=20
> On Tue, 20 Jun 2006, Andrew Finney wrote:
>=20
> > Rainer
> >
> >> do you know of any examples of models with a compartment with=20
> >> spatialDimension zero or hasOnlySubstanceUnits true?
> >>
> >
> > Darren Wilkinson created a stoctastic test suite which consists of=20
> > models of this form.  They should operate correctly in a=20
> deterministic=20
> > simulator as well.
> >
> >> can a compartment of dimension zero have a size?
> >
> > No
> >
> >>
> >> would we currently handle such structures correctly, at least for=20
> >> fixed compartment sizes?
> >
> > I don't see why not
> >
> > yours Andrew
> >
> >> -----Original Message-----
> >> From: Rainer Machne [mailto:ra...@tb...]
> >> Sent: 20 June 2006 15:48
> >> To: Andrew Finney
> >> Cc: SOSlib Development
> >> Subject: Re: [SOSlib-devel] variable compartment bug:=20
> >> example[Scanned]
> >>
> >>
> >>>>> The units of the species are of the form substance/size units
> >>
> >>> "The units of the species are of the form substance/size
> >> units (i.e.,
> >>> concentration units, using a broad definition of
> >> concentration) if the
> >>> compartment's spatialDimensions is non-zero and
> >> hasOnlySubstanceUnits
> >>> has the value ``false''. The units of the species are of the form=20
> >>> substance if spatialDimensions is zero or=20
> hasOnlySubstanceUnits has=20
> >>> the value ``true''. The units of substance are those=20
> defined in the=20
> >>> substanceUnits, and the size units are those given in the=20
> >>> spatialSizeUnits field."
> >>> ...
> >>
> >> oops, i guess it was some freudian process that blinded me to the=20
> >> continuation of this sentence :)
> >>
> >> do you know of any examples of models with a compartment with=20
> >> spatialDimension zero or hasOnlySubstanceUnits true?
> >>
> >> can a compartment of dimension zero have a size?
> >>
> >> would we currently handle such structures correctly, at least for=20
> >> fixed compartment sizes?
> >>
> >> BTW, there are several models with variable compartments=20
> in the test=20
> >> suite, all in the group rulesForParametersAndCompartments.
> >>
> >> Could it be that SOSlib only succeeded because the program used to=20
> >> generate tested results also does it wrong?
> >>
> >> Rainer
> >>
> >>
> >> On Tue, 20 Jun 2006, Andrew Finney wrote:
> >>
> >>> Rainer
> >>>
> >>>>>> of course you have to check if the species in your kinetic
> >>>> law have
> >>>>>> dimension conc or substance!
> >>>>>> sbml allows the usage of both, doesn't it?
> >>>>>
> >>>>> See section 4.6.4 here
> >>>>>
> >>>>
> >>=20
> http://sbml.org/specifications/sbml-level-2/version-1/html/sbml-level
> >>>> -
> >>>>> 2.html#SECTION00046000000000000000
> >>>>>
> >>>>> "
> >>>>> The units of the species are of the form substance/size units
> >>>>>
> >>>>> ...
> >>>>>
> >>>>> The units of the species are used in the following ways:
> >>>>>
> >>>>> ...
> >>>>>    * The species identifier has these units when it=20
> appears as a=20
> >>>>> numerical quantity in a mathematical formula expressed=20
> in MathML=20
> >>>>> (discussed in Section 3.6.3).
> >>>>> "
> >>>>>
> >>>>> So i guess, the units of species in math expressions are
> >> always in
> >>>>> concentrations!
> >>>>>
> >>>
> >>> WRONG
> >>>
> >>> They are either substance or concentration units depending on the=20
> >>> attributes of the species element.
> >>>
> >>> "The units of the species are of the form substance/size
> >> units (i.e.,
> >>> concentration units, using a broad definition of
> >> concentration) if the
> >>> compartment's spatialDimensions is non-zero and
> >> hasOnlySubstanceUnits
> >>> has the value ``false''. The units of the species are of the form=20
> >>> substance if spatialDimensions is zero or=20
> hasOnlySubstanceUnits has=20
> >>> the value ``true''. The units of substance are those=20
> defined in the=20
> >>> substanceUnits, and the size units are those given in the=20
> >>> spatialSizeUnits field."
> >>> ...
> >>>
> >>> "The units of the species are used in the following ways:
> >>>
> >>>
> >>> The species initialConcentration field has these units=20
> (see Section=20
> >>> 4.6.3).
> >>>
> >>> The species identifier has these units when it appears as a
> >> numerical
> >>> quantity in a mathematical formula expressed in MathML
> >> (discussed in
> >>> Section 3.6.3).
> >>>
> >>> The math field of an AssignmentRule structure determining
> >> the species'
> >>> quantity (see Section 4.8.2) has these units.
> >>>
> >>> In RateRule structures that set the rate of change of the species'
> >>> quantity (Section 4.8.3), the units on the rule's math
> >> field are the
> >>> units of the species divided by the built-in time units. "
> >>>
> >>> yours Andrew
> >>>
> >>>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: sbm...@li...
> >>>> [mailto:sbm...@li...] On
> >> Behalf Of
> >>>> Rainer Machne
> >>>> Sent: 20 June 2006 15:26
> >>>> To: Stefan Mueller
> >>>> Cc: sbm...@li...
> >>>> Subject: Re: [SOSlib-devel] variable compartment bug:
> >>>> example[Scanned]
> >>>>
> >>>>
> >>>>
> >>>> This
> >>>>
> >>>>> current ODE: d[S1]/dt =3D f(S1, S2, ...) / V planned ODE: d
> >> S1 /dt =3D
> >>>>> f(S1, S2, ...)
> >>>>
> >>>> should of course be
> >>>>
> >>>> current ODE: d[S1]/dt =3D f([S1], [S2], ...) / V planned ODE: d
> >>>> S1 /dt =3D f([S1], [S2], ...)
> >>>>
> >>>>
> >>>> On Tue, 20 Jun 2006, Rainer Machne wrote:
> >>>>
> >>>>> stefan
> >>>>>
> >>>>>
> >>>>>>> divide k by V(0) and the whole kinetic law again by=20
> V^2 for 2nd=20
> >>>>>>> order reactions
> >>>>>>
> >>>>>> yes.
> >>>>>> and that's exactly the same what you are planning, if you
> >>>> want to use
> >>>>>> conc ans subst in parallel.
> >>>>>> only the point of conversion differs.
> >>>>>
> >>>>> not really. i wasn't planning any conversion of the math,
> >>>> except for:
> >>>>>
> >>>>> current ODE: d[S1]/dt =3D f(S1, S2, ...) / V planned ODE: d
> >> S1 /dt =3D
> >>>>> f(S1, S2, ...)
> >>>>>
> >>>>> then we have two data->value arrays, let's say
> >>>>>
> >>>>> data->odeValues =3D S1, S2, S3, etc.
> >>>>> and
> >>>>> data->concValues =3D [S1], [S2], [S3] etc.
> >>>>>
> >>>>>
> >>>>> The first array `odeValues' corresponds to the SUNDIALS
> >>>> values in NVector y.
> >>>>> The second array `concValues' will be used in evaluateAST, for=20
> >>>>> evaluation the math.
> >>>>>
> >>>>>
> >>>>> This would be equivalent of course, with just replacing
> >> all [S1] in
> >>>>> all math expressions with S1/volume, and only using one array
> >>>>> data->odeValues
> >>>>>
> >>>>> While the latter approach might be easier to implement it has a=20
> >>>>> probably the not so small drawback, that for each species
> >>>> in each math
> >>>>> expression the evaluation needs one more operation, i.e.
> >>>> the division,
> >>>>> while this division could be done only once for each
> >>>> species whenever
> >>>>> data->odeValues is updated (i.e. e.g. in the
> >>>> SOSlib/SUNDIALS funciton f).
> >>>>>
> >>>>> However, this might still only be correct, if compartments are=20
> >>>>> determined by assignment rules.
> >>>>> If they are determined by rate rules, then the replacement
> >>>> S1 -> S1/V
> >>>>> would also be required for constructing the jacobi matrix.
> >>>>>
> >>>>>> of course you have to check if the species in your kinetic
> >>>> law have
> >>>>>> dimension conc or substance!
> >>>>>> sbml allows the usage of both, doesn't it?
> >>>>>
> >>>>> See section 4.6.4 here
> >>>>>
> >>>>
> >>=20
> http://sbml.org/specifications/sbml-level-2/version-1/html/sbml-level
> >>>> -
> >>>>> 2.html#SECTION00046000000000000000
> >>>>>
> >>>>> "
> >>>>> The units of the species are of the form substance/size units
> >>>>>
> >>>>> ...
> >>>>>
> >>>>> The units of the species are used in the following ways:
> >>>>>
> >>>>> ...
> >>>>>    * The species identifier has these units when it=20
> appears as a=20
> >>>>> numerical quantity in a mathematical formula expressed=20
> in MathML=20
> >>>>> (discussed in Section 3.6.3).
> >>>>> "
> >>>>>
> >>>>> So i guess, the units of species in math expressions are
> >> always in
> >>>>> concentrations!
> >>>>>
> >>>>> Rainer
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>
> >>>>>> i mean, every species is in a well-defined=20
> compartment, isn't it?
> >>>>>> so you can use the formula [S]=3DS/V whenever you want...
> >>>>>>
> >>>>>> i would eliminate conc as early as possile, but that's a
> >> matter of
> >>>>> taste.
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Tue, 20 Jun 2006, Stefan Mueller wrote:
> >>>>>
> >>>>>> hi rainer!
> >>>>>>
> >>>>>>> stefan
> >>>>>>>
> >>>>>>>>> Currently the ODE would be:
> >>>>>>>>>
> >>>>>>>>> d[S1]/dt =3D k1 * [S1] / V1
> >>>>>>>>
> >>>>>>>> this is not valid for variable compartments.
> >>>>>>>
> >>>>>>> i said that it's invalid for variable compartments some
> >>>> lines below:
> >>>>>>>>> which is only valid for constant compartments V1 and V2.
> >>>>>>>>
> >>>>>>>> please don't use it for comparison!
> >>>>>>>
> >>>>>>> it's not used for comparison, but it is the current
> >>>> implementation
> >>>>>>> in SOSlib!
> >>>>>>
> >>>>>> i said this just to avoid any additional misunderstanding.
> >>>>>> the whole topic seems to be quite confusing...
> >>>>>>
> >>>>>>>>> At least for the second ODE, depending in two different
> >>>> volumes,
> >>>>>>>>> the conversion to ODEs depending on substance instead of=20
> >>>>>>>>> concentration is not as simple as
> >>>>>>>>>
> >>>>>>>>>> dS1/dt =3D k * [S1] * [S2] / V(0) * V =3D k/V(0) * S1 * S2 =
/ V
> >>>>>>>>
> >>>>>>>> why dou you refer to this law for a reaction of order 2?
> >>>>>>>
> >>>>>>> sorry, at first i wanted to make the second reaction in
> >> V2 of 2nd
> >>>>>>> order, e.g.,
> >>>>>>>
> >>>>>>> in V2:
> >>>>>>> S2 + S3 -> P: k2*[S2]*[S3]
> >>>>>>>
> >>>>>>>>> as your example before,
> >>>>>>>>> but for S2 I get:
> >>>>>>>>>
> >>>>>>>>> dS2/dt =3D k1/V1(0) * S1/V1 * V2  -  k2/V2(0) * S2
> >>>>>>>>>
> >>>>>>>>> Right?
> >>>>>>>>
> >>>>>>>> no!
> >>>>>>>> dS2/dt =3D k1/V1(0) * S1 - k2/V2(0) * S2 it's as=20
> simple as that!
> >>>>>>>> (since dS2/dt =3D -dS1/dt as far as reaction S1->S2 is
> >> concerned.)
> >>>>>>>> that's the advantage of kinetic laws (and consequently
> >> odes) for
> >>>>>>>> substances!
> >>>>>>>
> >>>>>>> of course! sorry, i got quite confused obviously.
> >>>>>>>
> >>>>>>> and for the above second order reaction in V2 it would be:
> >>>>>>>
> >>>>>>>   dS2/dt =3D k1/V1(0) * S1 - k2/V2(0) * S1 * S3 / V2
> >>>>>>>
> >>>>>>> Right this time?
> >>>>>>
> >>>>>> yes :)
> >>>>>>
> >>>>>>>>> Thus I would really have to check the type of reaction
> >>>> and edit a
> >>>>>>>>> lot of kinetic laws before constructing the ODEs.
> >>>>>>>>
> >>>>>>>> the above example shows that this is not necessary.
> >>>>>>>> maybe there are other examples...
> >>>>>>>
> >>>>>>> so you say, we could convert kinetic laws that don't=20
> explicitly=20
> >>>>>>> contain the volume by simply differentiating these
> >> three cases and
> >>>>>>>
> >>>>>>>>>> order 1:
> >>>>>>>>>> S1->junk: k*[S1]
> >>>>>>>>>> dS1/dt =3D k * [S1] / V(0) * V =3D k/V(0) * S1
> >>>>>>>
> >>>>>>> divide k by V(0) for 1st order reactions
> >>>>>>>
> >>>>>>>>>> order 2:
> >>>>>>>>>> S1+S2->bla: k*[S1]*[S2]
> >>>>>>>>>> dS1/dt =3D k * [S1] * [S2] / V(0) * V =3D k/V(0) * S1 * S2 =
/ V
> >>>>>>>
> >>>>>>> divide k by V(0) and the whole kinetic law again by=20
> V^2 for 2nd=20
> >>>>>>> order reactions
> >>>>>>>
> >>>>>>>>>> order 3:
> >>>>>>>>>> S1+S2+S3->wow: k*[S1]*[S2]*[S3]
> >>>>>>>>>> dS1/dt =3D k * [S1] * [S2] * [S3] / V(0) * V =3D k/V(0) *
> >>>> S1 * S2 *
> >>>>>>>>>> S3 /
> >>>>>>>
> >>>>>>> V^2
> >>>>>>>
> >>>>>>> divide k by V(0) and the whole kinetic law again by=20
> V^2 for 2nd=20
> >>>>>>> order reactions
> >>>>>>
> >>>>>> yes.
> >>>>>> and that's exactly the same what you are planning, if you
> >>>> want to use
> >>>>>> conc ans subst in parallel.
> >>>>>> only the point of conversion differs.
> >>>>>>
> >>>>>> i mean, every species is in a well-defined=20
> compartment, isn't it?
> >>>>>> so you can use the formula [S]=3DS/V whenever you want...
> >>>>>>
> >>>>>> i would eliminate conc as early as possile, but that's a
> >>>> matter of taste.
> >>>>>>
> >>>>>>> but there are also enzymatic reactions, with in often
> >>>> quite complex
> >>>>>>> kinetic laws. we would really have to do unit checking,
> >>>> recognizing
> >>>>>>> the implemented reaction mechanisms etc.
> >>>>>>
> >>>>>> of course you have to check if the species in your kinetic
> >>>> law have
> >>>>>> dimension conc or substance!
> >>>>>> sbml allows the usage of both, doesn't it?
> >>>>>>
> >>>>>>> also, we don't really know in which compartment
> >> reactions happen,
> >>>>>>> but could just try to get this information from the
> >>>> reactants' compartments.
> >>>>>>
> >>>>>> this does not matter, for 2 reasons:
> >>>>>>
> >>>>>> 1. if the kinetic law is specified correctly (including the=20
> >>>>>> compartment size), e.g. A+B->C: k*V*[A]*[B], the the
> >>>> compartment size
> >>>>>> is considered automatically.
> >>>>>>
> >>>>>> 2. the conversion [S]=3DS/V does not depend on reactions,
> >>>> but only on
> >>>>>> species (and their compartments).
> >>>>>>
> >>>>>>> so i guess, it would be much easier to
> >>>>>>>
> >>>>>>> a) use ODEs for substances but dependent on
> >>>> concentrations, here the
> >>>>>>> only thing we need to do is to leave out the compartment
> >>>> division at
> >>>>>>> the end of Species_odeFromReactions and have a double
> >>>> bookkeeping of
> >>>>>>> amounts and concentrations
> >>>>>>
> >>>>>> to my taste, double book keeping is dangerous and produces
> >>>> overhead.
> >>>>>>
> >>>>>>> and
> >>>>>>>
> >>>>>>> b) just ignore WRONG models that have a variable
> >> compartment but
> >>>>>>> don't have the compartment explicitly in their=20
> kinetic laws (or=20
> >>>>>>> check for such cases and issue an error);
> >>>>>>>
> >>>>>>> isn't it an issue of correct model writing rather then
> >>>> correct model
> >>>>>>> solving?
> >>>>>>
> >>>>>> i agree.
> >>>>>>
> >>>>>>> However, another problem might be that to calculate=20
> in amounts=20
> >>>>>>> rather then in concentrations also changes the use of=20
> absolute=20
> >>>>>>> errors and maybe also the general the performance of the
> >>>> integrator, i guess. ??
> >>>>>>
> >>>>>> abs errors might change, but that's not an issue.
> >>>>>> rel errors should stay the same.
> >>>>>> (in one-compartment models everything is just multiplied by the
> >>>>>> volume.)
> >>>>>>
> >>>>>>> maybe we will have to really implement both in parallel,
> >>>>>>
> >>>>>> i hope not :)
> >>>>>>
> >>>>>>> * ODEs for concentrations/time if no variable
> >> compartments are in
> >>>>>>> the model
> >>>>>>> * ODEs for ammounts/time if any compartment is variable
> >>>>>>>
> >>>>>>> ?
> >>>>>>>
> >>>>>>> Rainer
> >>>>>>
> >>>>>> maybe we discuss the next round via telephone :)
> >>>>>>
> >>>>>> cheers, s
> >>>>>>
> >>>>>>
> >>>>>>>>> Thus I think it just doesn't work with kinetic laws
> >> that don't
> >>>>>>>>> include the compartment explicitly!
> >>>>>>>>
> >>>>>>>> i don't know exactly what you mean.
> >>>>>>>> of course kinetic laws with explicit compartment are
> >>>> "nicer", but
> >>>>>>>> you can always transform any kinetic law to a "nice" one...
> >>>>>>>>
> >>>>>>>>> But if they include the compartment we can write ODEs for=20
> >>>>>>>>> substances but have concentrations in the right hand
> >>>> side of the
> >>>>>>>>> ODEs. We then just need to a second array for the
> >>>> concentrations, as discussed before.
> >>>>>>>>
> >>>>>>>> if we still use concentrations is a separate problem,
> >>>> independent
> >>>>>>>> of which we discussed until now.
> >>>>>>>> it's a matter of taste, if we eliminate the
> >> concentrations  from
> >>>>>>>> the kinetic laws and get a (possibly nonlinear)
> >>>> dependence on the
> >>>>>>>> compartments OR if we keep concentrations and always
> >> have linear
> >>>>>>>> dependence on the comp.
> >>>>>>>>
> >>>>>>>>> Rainer
> >>>>>>>>
> >>>>>>>> cheers,
> >>>>>>>> stefan.
> >>>>>>>>
> >>>>>>>>> On Mon, 19 Jun 2006, Stefan Mueller wrote:
> >>>>>>>>>> let me summarize:
> >>>>>>>>>> kinetic laws have units substance/time, and they depend on=20
> >>>>>>>>>> concentrations or substances.
> >>>>>>>>>>
> >>>>>>>>>> we SHOULD write down odes for substances, and we COULD
> >>>> eliminate
> >>>>>>>>>> concs completely.
> >>>>>>>>>> (of course, we would have to convert initial concs to
> >>>>>>>>>> substances.)
> >>>>>>>>>>
> >>>>>>>>>> in any case, odes for substances depend on the
> >>>> compartment size
> >>>>>>>>>> (linearly or according to the order of the reaction):
> >>>>>>>>>>
> >>>>>>>>>> order 1:
> >>>>>>>>>> S1->junk: k*[S1]
> >>>>>>>>>> dS1/dt =3D k * [S1] / V(0) * V =3D k/V(0) * S1
> >>>>>>>>>>
> >>>>>>>>>> order 2:
> >>>>>>>>>> S1+S2->bla: k*[S1]*[S2]
> >>>>>>>>>> dS1/dt =3D k * [S1] * [S2] / V(0) * V =3D k/V(0) * S1 * S2 =
/ V
> >>>>>>>>>>
> >>>>>>>>>> order 3:
> >>>>>>>>>> S1+S2+S3->wow: k*[S1]*[S2]*[S3]
> >>>>>>>>>> dS1/dt =3D k * [S1] * [S2] * [S3] / V(0) * V =3D k/V(0) *
> >>>> S1 * S2 *
> >>>>>>>>>> S3 /
> >>>>>>>>>> V^2
> >>>>>>>>>>
> >>>>>>>>>> ...
> >>>>>>>>>>
> >>>>>>>>>> if the kinetic laws included the compartment
> >>>> explicitly (which is
> >>>>>>>>>> desirable), we would have the following situation:
> >>>>>>>>>>
> >>>>>>>>>> order 1:
> >>>>>>>>>> S1->junk: r*[S1]*V
> >>>>>>>>>> dS1/dt =3D  r * [S1] * V=3D r * S1
> >>>>>>>>>>
> >>>>>>>>>> order 2:
> >>>>>>>>>> S1+S2->bla: r*[S1]*[S2]*V
> >>>>>>>>>> dS1/dt =3D r * [S1] * [S2] * V=3D r * S1 * S2 / V
> >>>>>>>>>>
> >>>>>>>>>> order 3:
> >>>>>>>>>> S1+S2+S3->wow: r*[S1]*[S2]*[S3]*V
> >>>>>>>>>> dS1/dt =3D r * [S1] * [S2] * [S3] * V =3D r * S1 * S2=20
> * S3 / V^2
> >>>>>>>>>>
> >>>>>>>>>> as stated earlier, odes for substances have got another=20
> >>>>>>>>>> advantage. for the compartment size we could use
> >> either a rate
> >>>>>>>>>> rule or an assignment
> >>>>>>>>>> rule: dV/dt =3D f(t, V, ...)
> >>>>>>>>>> or
> >>>>>>>>>> V=3D f(t, V, ...)
> >>>>>>>>>>
> >>>>>>>>>> cheers,
> >>>>>>>>>> stefan.
> >>>>>>>>>>
> >>>>>>>>>> Am Montag 19 Juni 2006 11:17 schrieb Stefan Mueller:
> >>>>>>>>>>> andrew:
> >>>>>>>>>>>
> >>>>>>>>>>> for the SBML system
> >>>>>>>>>>> 	S1 in C
> >>>>>>>>>>> 	S1->junk : k * [S1]
> >>>>>>>>>>> 	dC/dt =3D 1
> >>>>>>>>>>>
> >>>>>>>>>>> the right math is:
> >>>>>>>>>>> 	dS1/dt =3D k * [S1] / C(0) * C
> >>>>>>>>>>> 	dC/dt =3D 1
> >>>>>>>>>>> with initial cond:
> >>>>>>>>>>> 	S1(0) =3D [S1](0) * C(0)
> >>>>>>>>>>> 	C(0)
> >>>>>>>>>>>
> >>>>>>>>>>> notation:
> >>>>>>>>>>> 	S1 ... substance
> >>>>>>>>>>> 	[S1] ... conc
> >>>>>>>>>>>
> >>>>>>>>>>> the "proposed solution" (who proposed this?) has=20
> the right=20
> >>>>>>>>>>> units, but is wrong otherwise... :)
> >>>>>>>>>>>
> >>>>>>>>>>> as rainer and me already discussed, everything
> >> would be much
> >>>>>>>>>>> clearer, if the kinetic law included the compartment
> >>>> explicitly:
> >>>>>>>>>>> 	S1 in C
> >>>>>>>>>>> 	S1->junk : C * r * [S1]
> >>>>>>>>>>> 	dC/dt =3D 1
> >>>>>>>>>>>
> >>>>>>>>>>> with:
> >>>>>>>>>>> 	r ... the "real" chemical rate constant.
> >>>>>>>>>>>
> >>>>>>>>>>> rainer:
> >>>>>>>>>>>
> >>>>>>>>>>> chemists always knew that rate constants are not
> >>>> constant with
> >>>>>>>>>>> respect to pH, T, ... as a physicist i have to be fair! :)
> >>>>>>>>>>>
> >>>>>>>>>>> to conclude: the math is not really tricky.
> >>>>>>>>>>> odes for substances are better suited to handle
> >> both multiple
> >>>>>>>>>>> and variable compartments. of course, we have to
> >> take care of
> >>>>>>>>>>> many implementation details...
> >>>>>>>>>>>
> >>>>>>>>>>> cheers,
> >>>>>>>>>>> stefan.
> >>>>>>>>>>
> >>>>>>>>>> _______________________________________________
> >>>>>>>>>> sbmlsolver-devel mailing list=20
> >>>>>>>>>> sbm...@li...
> >>>>>>>>>>=20
> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
> >>>>>>>>>
> >>>>>>>>> _______________________________________________
> >>>>>>>>> sbmlsolver-devel mailing list
> >>>>>>>>> sbm...@li...
> >>>>>>>>>=20
> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
> >>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>>>> sbmlsolver-devel mailing list
> >>>>>>>> sbm...@li...
> >>>>>>>> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> sbmlsolver-devel mailing list
> >>>>>>> sbm...@li...
> >>>>>>> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
> >>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> sbmlsolver-devel mailing list
> >>>>>> sbm...@li...
> >>>>>> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> sbmlsolver-devel mailing list
> >>>> sbm...@li...
> >>>> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
> >>>>
> >>>
> >>>
> >>> _______________________________________________
> >>> sbmlsolver-devel mailing list
> >>> sbm...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
> >>>
> >>
> >
> >
> > _______________________________________________
> > sbmlsolver-devel mailing list
> > sbm...@li...
> > https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
> >
>=20

Re: [SOSlib-devel] implementing variable compartments[Scanned]

[Stefan M. <ste...@oe...>]

rainer!

> Yes you are right. my mistake. We only need the
> * additional assignment rules for all species x = x.amount,

that would be too easy! :)
x = x.amount / V

> * formulate ODEs for new variables x.amount and leave away the  ... /
> volume from current ODEs
>
> and everything, incl. the jacobian, should be fine ( i hope ).

yes, that's easy!
before the symbolic differentiations (for the jacobian) are done,
all conc have to be eliminated from the rhs of the odes. 
(via the above formula.)
but this is done anyway, isn't it?

> of course we haven't considered the `hasSubstanceUnits-species' ...
>
> wow :) such an easy conclusion for such a long and confusing discussion. i
> am really not a `formula-person' :)

for me as a formula person :), the most difficult problem was to understand 
which odes remain valid in the case of variable compartments:
the odes for conc or the odes for substances?
with hindsight, it seems clear: the odes for substances!

anyway, there exist correct odes for both conc and substances.
(with a correction term for the former.)
as a consequence, the implementation of the latter is simpler!

cheers,
s

> rainer
>
> > I don't think you need to actually substitute the x.amount/volume into
> > the
> > ODEs if you have the assignment rules.  In SOSlib
>
> On Fri, 23 Jun 2006, Andrew Finney wrote:
> > Folks
> >
> > So what your suggesting is pretty simple:
> > for any SBML system always transform the system to
> > create ODEs of rates of substance change
> > and assignment rules that derive concentrations from substance.
> >
> > That's pretty straightforward I think.  I'm happy.
> >
> > Note:
> >
> > I don't think you need to actually substitute the x.amount/volume into
> > the
> > ODEs if you have the assignment rules.  In SOSlib
> >
> > x2 = x2.amount/volume
> > dx1.amount/dt = k * x2
> > dx2.amount/dt = ???
> >
> > should be equivalent to:
> >
> > dx1.amount/dt = k * (x2.amount/volume)
> > dx2.amount/dt = ???
> >
> > This works because the relevant assignment rules are evaluated in the
> > CVODE rhs function
> > before evaluating the ODEs themselves.
> >
> > Or am I missing something? An issue with the jacobian???
> >
> > If the above isn't true then the way assignment rules work
> > in the general case is wrong too.
> >
> > yours Andrew
> >
> >> -----Original Message-----
> >> From: sbm...@li...
> >> [mailto:sbm...@li...] On
> >> Behalf Of Stefan Mueller
> >> Sent: 21 June 2006 16:51
> >> To: sbm...@li...
> >> Subject: Re: [SOSlib-devel] implementing variable
> >> compartments[Scanned]
> >>
> >> rainer
> >>
> >>> Stefan, thanks for the clarification in your last email.
> >>>
> >>> i think i got it now :)
> >>>
> >>> you wrote:
> >>>> the ode for conc can be derived by differentiating x=X/V:
> >>>> dx/dt = (dX/dt)/V - x*(dV/dt)/V
> >>>> where dX/dt is given by the kinetic law above.
> >>>
> >>> dX/dt is just the sum of the +/- (stoichiometry*kineticLaw)
> >>> expressions for all reactions where X is a
> >>
> >> product/reactant, i.e. it
> >>
> >>> is a function of concentrations x, y, z ...
> >>>
> >>> Right? (If not forget, the rest ...)
> >>
> >> right.
> >>
> >>> So actually, the first part of this equation (dX/dt)/V is
> >>
> >> the current
> >>
> >>> form of ODEs in SOSlib!
> >>>
> >>> Could the implementation of variable compartments in SOSlib
> >>
> >> would be
> >>
> >>> as easy as:
> >>>
> >>> 1) add the expression " - x*(dV/dt)/V "
> >>> to the concentration ODEs for species in a variable compartment?
> >>
> >> yes.
> >>
> >>> 2a) if the compartment is defined by a rate rule, this rate
> >>
> >> rule could
> >>
> >>> be appended to all ODEs directly, i.e.
> >>>
> >>> newODE = currentODE - (x/V) * rateRule
> >>
> >> yes.
> >>
> >>> 2b) if the compartment is defined by an assignment rule, we
> >>
> >> would have
> >>
> >>> differentiate it towards time? For this we need to convert the
> >>> assignment rule to a form, where differentiateAST recognizes time
> >>> dependent variables that are in the assignment rule, e.g.
> >>
> >> x(t), which
> >>
> >>> appears only as ASTNode "x". Is this possible/easy?
> >>
> >> possible.
> >> easy? differentiateAST has to extended.
> >> there must be differentiation with respect to time, but only
> >> variables for which there is an ode are differentiated.
> >> (and the rhs of the ode is the result.)
> >> the chain rule does the rest of the work...
> >>
> >>> 2c) if the compartment is changed by events, we don't need
> >>
> >> to append
> >>
> >>> anything but just recalculate concentrations and re-initialize the
> >>> solver, just as we do now for events.
> >>>
> >>>
> >>> If above is right - but i guess it might just not be that easy - we
> >>> would have extracted two alternatives:
> >>>
> >>> A) use ODEs in substance/time, write assignment rules for
> >>
> >> x.amount = x
> >>
> >>> / volume and replace all x by x.amount in ODEs, as Andrew suggested
> >>
> >> you mean: x = x.amount / volume !?
> >>
> >>> or
> >>>
> >>> B) use above approach.
> >>>
> >>> Is that it?
> >>
> >> yes.
> >> i vote for alternative A :)
> >>
> >> reason:
> >> (i) in alternative B you have to do point 1 and 2a, the
> >> volume correction, for each ode.
> >> (ii) in alternative B you have to do point 2b, the additional
> >> differentiation.
> >> (iii) the use of assignment rules x = x.amount / volume are
> >> not a criterion.
> >> they can be used in both alternatives.
> >>
> >> cheers, s
> >>
> >>> Rainer
> >>> _______________________________________________
> >>> sbmlsolver-devel mailing list
> >>> sbm...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
> >>
> >> _______________________________________________
> >> sbmlsolver-devel mailing list
> >> sbm...@li...
> >> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel

Re: [SOSlib-devel] spatial dimension zero

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

>> can a compartment of dimension zero have a size?
>
> No
>
>>
>> would we currently handle such structures correctly, at least
>> for fixed compartment sizes?
>
> I don't see why not

Mhm, I guess we might get an error for Compartment_getValue, because at 
the moment I think we treat all compartments as a constant having a size. 
E.g. all ODEs are automatically divided by the compartment size.

Is the stochastic test suite with such models available yet?

Rainer


On Tue, 20 Jun 2006, Andrew Finney wrote:

> Rainer
>
>> do you know of any examples of models with a compartment with
>> spatialDimension zero or hasOnlySubstanceUnits true?
>>
>
> Darren Wilkinson created a stoctastic test suite which consists of
> models
> of this form.  They should operate correctly in a deterministic
> simulator as well.
>
>> can a compartment of dimension zero have a size?
>
> No
>
>>
>> would we currently handle such structures correctly, at least
>> for fixed compartment sizes?
>
> I don't see why not
>
> yours Andrew
>
>> -----Original Message-----
>> From: Rainer Machne [mailto:ra...@tb...]
>> Sent: 20 June 2006 15:48
>> To: Andrew Finney
>> Cc: SOSlib Development
>> Subject: Re: [SOSlib-devel] variable compartment bug: example[Scanned]
>>
>>
>>>>> The units of the species are of the form substance/size units
>>
>>> "The units of the species are of the form substance/size
>> units (i.e.,
>>> concentration units, using a broad definition of
>> concentration) if the
>>> compartment's spatialDimensions is non-zero and
>> hasOnlySubstanceUnits
>>> has the value ``false''. The units of the species are of the form
>>> substance if spatialDimensions is zero or hasOnlySubstanceUnits has
>>> the value ``true''. The units of substance are those defined in the
>>> substanceUnits, and the size units are those given in the
>>> spatialSizeUnits field."
>>> ...
>>
>> oops, i guess it was some freudian process that blinded me to
>> the continuation of this sentence :)
>>
>> do you know of any examples of models with a compartment with
>> spatialDimension zero or hasOnlySubstanceUnits true?
>>
>> can a compartment of dimension zero have a size?
>>
>> would we currently handle such structures correctly, at least
>> for fixed compartment sizes?
>>
>> BTW, there are several models with variable compartments in
>> the test suite, all in the group rulesForParametersAndCompartments.
>>
>> Could it be that SOSlib only succeeded because the program
>> used to generate tested results also does it wrong?
>>
>> Rainer
>>
>>
>> On Tue, 20 Jun 2006, Andrew Finney wrote:
>>
>>> Rainer
>>>
>>>>>> of course you have to check if the species in your kinetic
>>>> law have
>>>>>> dimension conc or substance!
>>>>>> sbml allows the usage of both, doesn't it?
>>>>>
>>>>> See section 4.6.4 here
>>>>>
>>>>
>> http://sbml.org/specifications/sbml-level-2/version-1/html/sbml-level
>>>> -
>>>>> 2.html#SECTION00046000000000000000
>>>>>
>>>>> "
>>>>> The units of the species are of the form substance/size units
>>>>>
>>>>> ...
>>>>>
>>>>> The units of the species are used in the following ways:
>>>>>
>>>>> ...
>>>>>    * The species identifier has these units when it appears as a
>>>>> numerical quantity in a mathematical formula expressed in MathML
>>>>> (discussed in Section 3.6.3).
>>>>> "
>>>>>
>>>>> So i guess, the units of species in math expressions are
>> always in
>>>>> concentrations!
>>>>>
>>>
>>> WRONG
>>>
>>> They are either substance or concentration units depending on the
>>> attributes of the species element.
>>>
>>> "The units of the species are of the form substance/size
>> units (i.e.,
>>> concentration units, using a broad definition of
>> concentration) if the
>>> compartment's spatialDimensions is non-zero and
>> hasOnlySubstanceUnits
>>> has the value ``false''. The units of the species are of the form
>>> substance if spatialDimensions is zero or hasOnlySubstanceUnits has
>>> the value ``true''. The units of substance are those defined in the
>>> substanceUnits, and the size units are those given in the
>>> spatialSizeUnits field."
>>> ...
>>>
>>> "The units of the species are used in the following ways:
>>>
>>>
>>> The species initialConcentration field has these units (see Section
>>> 4.6.3).
>>>
>>> The species identifier has these units when it appears as a
>> numerical
>>> quantity in a mathematical formula expressed in MathML
>> (discussed in
>>> Section 3.6.3).
>>>
>>> The math field of an AssignmentRule structure determining
>> the species'
>>> quantity (see Section 4.8.2) has these units.
>>>
>>> In RateRule structures that set the rate of change of the species'
>>> quantity (Section 4.8.3), the units on the rule's math
>> field are the
>>> units of the species divided by the built-in time units. "
>>>
>>> yours Andrew
>>>
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: sbm...@li...
>>>> [mailto:sbm...@li...] On
>> Behalf Of
>>>> Rainer Machne
>>>> Sent: 20 June 2006 15:26
>>>> To: Stefan Mueller
>>>> Cc: sbm...@li...
>>>> Subject: Re: [SOSlib-devel] variable compartment bug:
>>>> example[Scanned]
>>>>
>>>>
>>>>
>>>> This
>>>>
>>>>> current ODE: d[S1]/dt = f(S1, S2, ...) / V planned ODE: d
>> S1 /dt =
>>>>> f(S1, S2, ...)
>>>>
>>>> should of course be
>>>>
>>>> current ODE: d[S1]/dt = f([S1], [S2], ...) / V planned ODE: d
>>>> S1 /dt = f([S1], [S2], ...)
>>>>
>>>>
>>>> On Tue, 20 Jun 2006, Rainer Machne wrote:
>>>>
>>>>> stefan
>>>>>
>>>>>
>>>>>>> divide k by V(0) and the whole kinetic law again by V^2 for 2nd
>>>>>>> order reactions
>>>>>>
>>>>>> yes.
>>>>>> and that's exactly the same what you are planning, if you
>>>> want to use
>>>>>> conc ans subst in parallel.
>>>>>> only the point of conversion differs.
>>>>>
>>>>> not really. i wasn't planning any conversion of the math,
>>>> except for:
>>>>>
>>>>> current ODE: d[S1]/dt = f(S1, S2, ...) / V planned ODE: d
>> S1 /dt =
>>>>> f(S1, S2, ...)
>>>>>
>>>>> then we have two data->value arrays, let's say
>>>>>
>>>>> data->odeValues = S1, S2, S3, etc.
>>>>> and
>>>>> data->concValues = [S1], [S2], [S3] etc.
>>>>>
>>>>>
>>>>> The first array `odeValues' corresponds to the SUNDIALS
>>>> values in NVector y.
>>>>> The second array `concValues' will be used in evaluateAST, for
>>>>> evaluation the math.
>>>>>
>>>>>
>>>>> This would be equivalent of course, with just replacing
>> all [S1] in
>>>>> all math expressions with S1/volume, and only using one array
>>>>> data->odeValues
>>>>>
>>>>> While the latter approach might be easier to implement it has a
>>>>> probably the not so small drawback, that for each species
>>>> in each math
>>>>> expression the evaluation needs one more operation, i.e.
>>>> the division,
>>>>> while this division could be done only once for each
>>>> species whenever
>>>>> data->odeValues is updated (i.e. e.g. in the
>>>> SOSlib/SUNDIALS funciton f).
>>>>>
>>>>> However, this might still only be correct, if compartments are
>>>>> determined by assignment rules.
>>>>> If they are determined by rate rules, then the replacement
>>>> S1 -> S1/V
>>>>> would also be required for constructing the jacobi matrix.
>>>>>
>>>>>> of course you have to check if the species in your kinetic
>>>> law have
>>>>>> dimension conc or substance!
>>>>>> sbml allows the usage of both, doesn't it?
>>>>>
>>>>> See section 4.6.4 here
>>>>>
>>>>
>> http://sbml.org/specifications/sbml-level-2/version-1/html/sbml-level
>>>> -
>>>>> 2.html#SECTION00046000000000000000
>>>>>
>>>>> "
>>>>> The units of the species are of the form substance/size units
>>>>>
>>>>> ...
>>>>>
>>>>> The units of the species are used in the following ways:
>>>>>
>>>>> ...
>>>>>    * The species identifier has these units when it appears as a
>>>>> numerical quantity in a mathematical formula expressed in MathML
>>>>> (discussed in Section 3.6.3).
>>>>> "
>>>>>
>>>>> So i guess, the units of species in math expressions are
>> always in
>>>>> concentrations!
>>>>>
>>>>> Rainer
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> i mean, every species is in a well-defined compartment, isn't it?
>>>>>> so you can use the formula [S]=S/V whenever you want...
>>>>>>
>>>>>> i would eliminate conc as early as possile, but that's a
>> matter of
>>>>> taste.
>>>>>
>>>>>
>>>>>
>>>>> On Tue, 20 Jun 2006, Stefan Mueller wrote:
>>>>>
>>>>>> hi rainer!
>>>>>>
>>>>>>> stefan
>>>>>>>
>>>>>>>>> Currently the ODE would be:
>>>>>>>>>
>>>>>>>>> d[S1]/dt = k1 * [S1] / V1
>>>>>>>>
>>>>>>>> this is not valid for variable compartments.
>>>>>>>
>>>>>>> i said that it's invalid for variable compartments some
>>>> lines below:
>>>>>>>>> which is only valid for constant compartments V1 and V2.
>>>>>>>>
>>>>>>>> please don't use it for comparison!
>>>>>>>
>>>>>>> it's not used for comparison, but it is the current
>>>> implementation
>>>>>>> in SOSlib!
>>>>>>
>>>>>> i said this just to avoid any additional misunderstanding.
>>>>>> the whole topic seems to be quite confusing...
>>>>>>
>>>>>>>>> At least for the second ODE, depending in two different
>>>> volumes,
>>>>>>>>> the conversion to ODEs depending on substance instead of
>>>>>>>>> concentration is not as simple as
>>>>>>>>>
>>>>>>>>>> dS1/dt = k * [S1] * [S2] / V(0) * V = k/V(0) * S1 * S2 / V
>>>>>>>>
>>>>>>>> why dou you refer to this law for a reaction of order 2?
>>>>>>>
>>>>>>> sorry, at first i wanted to make the second reaction in
>> V2 of 2nd
>>>>>>> order, e.g.,
>>>>>>>
>>>>>>> in V2:
>>>>>>> S2 + S3 -> P: k2*[S2]*[S3]
>>>>>>>
>>>>>>>>> as your example before,
>>>>>>>>> but for S2 I get:
>>>>>>>>>
>>>>>>>>> dS2/dt = k1/V1(0) * S1/V1 * V2  -  k2/V2(0) * S2
>>>>>>>>>
>>>>>>>>> Right?
>>>>>>>>
>>>>>>>> no!
>>>>>>>> dS2/dt = k1/V1(0) * S1 - k2/V2(0) * S2 it's as simple as that!
>>>>>>>> (since dS2/dt = -dS1/dt as far as reaction S1->S2 is
>> concerned.)
>>>>>>>> that's the advantage of kinetic laws (and consequently
>> odes) for
>>>>>>>> substances!
>>>>>>>
>>>>>>> of course! sorry, i got quite confused obviously.
>>>>>>>
>>>>>>> and for the above second order reaction in V2 it would be:
>>>>>>>
>>>>>>>   dS2/dt = k1/V1(0) * S1 - k2/V2(0) * S1 * S3 / V2
>>>>>>>
>>>>>>> Right this time?
>>>>>>
>>>>>> yes :)
>>>>>>
>>>>>>>>> Thus I would really have to check the type of reaction
>>>> and edit a
>>>>>>>>> lot of kinetic laws before constructing the ODEs.
>>>>>>>>
>>>>>>>> the above example shows that this is not necessary.
>>>>>>>> maybe there are other examples...
>>>>>>>
>>>>>>> so you say, we could convert kinetic laws that don't explicitly
>>>>>>> contain the volume by simply differentiating these
>> three cases and
>>>>>>>
>>>>>>>>>> order 1:
>>>>>>>>>> S1->junk: k*[S1]
>>>>>>>>>> dS1/dt = k * [S1] / V(0) * V = k/V(0) * S1
>>>>>>>
>>>>>>> divide k by V(0) for 1st order reactions
>>>>>>>
>>>>>>>>>> order 2:
>>>>>>>>>> S1+S2->bla: k*[S1]*[S2]
>>>>>>>>>> dS1/dt = k * [S1] * [S2] / V(0) * V = k/V(0) * S1 * S2 / V
>>>>>>>
>>>>>>> divide k by V(0) and the whole kinetic law again by V^2 for 2nd
>>>>>>> order reactions
>>>>>>>
>>>>>>>>>> order 3:
>>>>>>>>>> S1+S2+S3->wow: k*[S1]*[S2]*[S3]
>>>>>>>>>> dS1/dt = k * [S1] * [S2] * [S3] / V(0) * V = k/V(0) *
>>>> S1 * S2 *
>>>>>>>>>> S3 /
>>>>>>>
>>>>>>> V^2
>>>>>>>
>>>>>>> divide k by V(0) and the whole kinetic law again by V^2 for 2nd
>>>>>>> order reactions
>>>>>>
>>>>>> yes.
>>>>>> and that's exactly the same what you are planning, if you
>>>> want to use
>>>>>> conc ans subst in parallel.
>>>>>> only the point of conversion differs.
>>>>>>
>>>>>> i mean, every species is in a well-defined compartment, isn't it?
>>>>>> so you can use the formula [S]=S/V whenever you want...
>>>>>>
>>>>>> i would eliminate conc as early as possile, but that's a
>>>> matter of taste.
>>>>>>
>>>>>>> but there are also enzymatic reactions, with in often
>>>> quite complex
>>>>>>> kinetic laws. we would really have to do unit checking,
>>>> recognizing
>>>>>>> the implemented reaction mechanisms etc.
>>>>>>
>>>>>> of course you have to check if the species in your kinetic
>>>> law have
>>>>>> dimension conc or substance!
>>>>>> sbml allows the usage of both, doesn't it?
>>>>>>
>>>>>>> also, we don't really know in which compartment
>> reactions happen,
>>>>>>> but could just try to get this information from the
>>>> reactants' compartments.
>>>>>>
>>>>>> this does not matter, for 2 reasons:
>>>>>>
>>>>>> 1. if the kinetic law is specified correctly (including the
>>>>>> compartment size), e.g. A+B->C: k*V*[A]*[B], the the
>>>> compartment size
>>>>>> is considered automatically.
>>>>>>
>>>>>> 2. the conversion [S]=S/V does not depend on reactions,
>>>> but only on
>>>>>> species (and their compartments).
>>>>>>
>>>>>>> so i guess, it would be much easier to
>>>>>>>
>>>>>>> a) use ODEs for substances but dependent on
>>>> concentrations, here the
>>>>>>> only thing we need to do is to leave out the compartment
>>>> division at
>>>>>>> the end of Species_odeFromReactions and have a double
>>>> bookkeeping of
>>>>>>> amounts and concentrations
>>>>>>
>>>>>> to my taste, double book keeping is dangerous and produces
>>>> overhead.
>>>>>>
>>>>>>> and
>>>>>>>
>>>>>>> b) just ignore WRONG models that have a variable
>> compartment but
>>>>>>> don't have the compartment explicitly in their kinetic laws (or
>>>>>>> check for such cases and issue an error);
>>>>>>>
>>>>>>> isn't it an issue of correct model writing rather then
>>>> correct model
>>>>>>> solving?
>>>>>>
>>>>>> i agree.
>>>>>>
>>>>>>> However, another problem might be that to calculate in amounts
>>>>>>> rather then in concentrations also changes the use of absolute
>>>>>>> errors and maybe also the general the performance of the
>>>> integrator, i guess. ??
>>>>>>
>>>>>> abs errors might change, but that's not an issue.
>>>>>> rel errors should stay the same.
>>>>>> (in one-compartment models everything is just multiplied by the
>>>>>> volume.)
>>>>>>
>>>>>>> maybe we will have to really implement both in parallel,
>>>>>>
>>>>>> i hope not :)
>>>>>>
>>>>>>> * ODEs for concentrations/time if no variable
>> compartments are in
>>>>>>> the model
>>>>>>> * ODEs for ammounts/time if any compartment is variable
>>>>>>>
>>>>>>> ?
>>>>>>>
>>>>>>> Rainer
>>>>>>
>>>>>> maybe we discuss the next round via telephone :)
>>>>>>
>>>>>> cheers, s
>>>>>>
>>>>>>
>>>>>>>>> Thus I think it just doesn't work with kinetic laws
>> that don't
>>>>>>>>> include the compartment explicitly!
>>>>>>>>
>>>>>>>> i don't know exactly what you mean.
>>>>>>>> of course kinetic laws with explicit compartment are
>>>> "nicer", but
>>>>>>>> you can always transform any kinetic law to a "nice" one...
>>>>>>>>
>>>>>>>>> But if they include the compartment we can write ODEs for
>>>>>>>>> substances but have concentrations in the right hand
>>>> side of the
>>>>>>>>> ODEs. We then just need to a second array for the
>>>> concentrations, as discussed before.
>>>>>>>>
>>>>>>>> if we still use concentrations is a separate problem,
>>>> independent
>>>>>>>> of which we discussed until now.
>>>>>>>> it's a matter of taste, if we eliminate the
>> concentrations  from
>>>>>>>> the kinetic laws and get a (possibly nonlinear)
>>>> dependence on the
>>>>>>>> compartments OR if we keep concentrations and always
>> have linear
>>>>>>>> dependence on the comp.
>>>>>>>>
>>>>>>>>> Rainer
>>>>>>>>
>>>>>>>> cheers,
>>>>>>>> stefan.
>>>>>>>>
>>>>>>>>> On Mon, 19 Jun 2006, Stefan Mueller wrote:
>>>>>>>>>> let me summarize:
>>>>>>>>>> kinetic laws have units substance/time, and they depend on
>>>>>>>>>> concentrations or substances.
>>>>>>>>>>
>>>>>>>>>> we SHOULD write down odes for substances, and we COULD
>>>> eliminate
>>>>>>>>>> concs completely.
>>>>>>>>>> (of course, we would have to convert initial concs to
>>>>>>>>>> substances.)
>>>>>>>>>>
>>>>>>>>>> in any case, odes for substances depend on the
>>>> compartment size
>>>>>>>>>> (linearly or according to the order of the reaction):
>>>>>>>>>>
>>>>>>>>>> order 1:
>>>>>>>>>> S1->junk: k*[S1]
>>>>>>>>>> dS1/dt = k * [S1] / V(0) * V = k/V(0) * S1
>>>>>>>>>>
>>>>>>>>>> order 2:
>>>>>>>>>> S1+S2->bla: k*[S1]*[S2]
>>>>>>>>>> dS1/dt = k * [S1] * [S2] / V(0) * V = k/V(0) * S1 * S2 / V
>>>>>>>>>>
>>>>>>>>>> order 3:
>>>>>>>>>> S1+S2+S3->wow: k*[S1]*[S2]*[S3]
>>>>>>>>>> dS1/dt = k * [S1] * [S2] * [S3] / V(0) * V = k/V(0) *
>>>> S1 * S2 *
>>>>>>>>>> S3 /
>>>>>>>>>> V^2
>>>>>>>>>>
>>>>>>>>>> ...
>>>>>>>>>>
>>>>>>>>>> if the kinetic laws included the compartment
>>>> explicitly (which is
>>>>>>>>>> desirable), we would have the following situation:
>>>>>>>>>>
>>>>>>>>>> order 1:
>>>>>>>>>> S1->junk: r*[S1]*V
>>>>>>>>>> dS1/dt =  r * [S1] * V= r * S1
>>>>>>>>>>
>>>>>>>>>> order 2:
>>>>>>>>>> S1+S2->bla: r*[S1]*[S2]*V
>>>>>>>>>> dS1/dt = r * [S1] * [S2] * V= r * S1 * S2 / V
>>>>>>>>>>
>>>>>>>>>> order 3:
>>>>>>>>>> S1+S2+S3->wow: r*[S1]*[S2]*[S3]*V
>>>>>>>>>> dS1/dt = r * [S1] * [S2] * [S3] * V = r * S1 * S2 * S3 / V^2
>>>>>>>>>>
>>>>>>>>>> as stated earlier, odes for substances have got another
>>>>>>>>>> advantage. for the compartment size we could use
>> either a rate
>>>>>>>>>> rule or an assignment
>>>>>>>>>> rule: dV/dt = f(t, V, ...)
>>>>>>>>>> or
>>>>>>>>>> V= f(t, V, ...)
>>>>>>>>>>
>>>>>>>>>> cheers,
>>>>>>>>>> stefan.
>>>>>>>>>>
>>>>>>>>>> Am Montag 19 Juni 2006 11:17 schrieb Stefan Mueller:
>>>>>>>>>>> andrew:
>>>>>>>>>>>
>>>>>>>>>>> for the SBML system
>>>>>>>>>>> 	S1 in C
>>>>>>>>>>> 	S1->junk : k * [S1]
>>>>>>>>>>> 	dC/dt = 1
>>>>>>>>>>>
>>>>>>>>>>> the right math is:
>>>>>>>>>>> 	dS1/dt = k * [S1] / C(0) * C
>>>>>>>>>>> 	dC/dt = 1
>>>>>>>>>>> with initial cond:
>>>>>>>>>>> 	S1(0) = [S1](0) * C(0)
>>>>>>>>>>> 	C(0)
>>>>>>>>>>>
>>>>>>>>>>> notation:
>>>>>>>>>>> 	S1 ... substance
>>>>>>>>>>> 	[S1] ... conc
>>>>>>>>>>>
>>>>>>>>>>> the "proposed solution" (who proposed this?) has the right
>>>>>>>>>>> units, but is wrong otherwise... :)
>>>>>>>>>>>
>>>>>>>>>>> as rainer and me already discussed, everything
>> would be much
>>>>>>>>>>> clearer, if the kinetic law included the compartment
>>>> explicitly:
>>>>>>>>>>> 	S1 in C
>>>>>>>>>>> 	S1->junk : C * r * [S1]
>>>>>>>>>>> 	dC/dt = 1
>>>>>>>>>>>
>>>>>>>>>>> with:
>>>>>>>>>>> 	r ... the "real" chemical rate constant.
>>>>>>>>>>>
>>>>>>>>>>> rainer:
>>>>>>>>>>>
>>>>>>>>>>> chemists always knew that rate constants are not
>>>> constant with
>>>>>>>>>>> respect to pH, T, ... as a physicist i have to be fair! :)
>>>>>>>>>>>
>>>>>>>>>>> to conclude: the math is not really tricky.
>>>>>>>>>>> odes for substances are better suited to handle
>> both multiple
>>>>>>>>>>> and variable compartments. of course, we have to
>> take care of
>>>>>>>>>>> many implementation details...
>>>>>>>>>>>
>>>>>>>>>>> cheers,
>>>>>>>>>>> stefan.
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> sbmlsolver-devel mailing list
>>>>>>>>>> sbm...@li...
>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> sbmlsolver-devel mailing list
>>>>>>>>> sbm...@li...
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> sbmlsolver-devel mailing list
>>>>>>>> sbm...@li...
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> sbmlsolver-devel mailing list
>>>>>>> sbm...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> sbmlsolver-devel mailing list
>>>>>> sbm...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> sbmlsolver-devel mailing list
>>>> sbm...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>>>>
>>>
>>>
>>> _______________________________________________
>>> sbmlsolver-devel mailing list
>>> sbm...@li...
>>> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>>>
>>
>
>
> _______________________________________________
> sbmlsolver-devel mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>

Re: [SOSlib-devel] implementing variable compartments[Scanned]

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

Yes you are right. my mistake. We only need the
* additional assignment rules for all species x = x.amount,
* formulate ODEs for new variables x.amount and leave away the  ... / 
volume from current ODEs

and everything, incl. the jacobian, should be fine ( i hope ).

of course we haven't considered the `hasSubstanceUnits-species' ...

wow :) such an easy conclusion for such a long and confusing discussion. i 
am really not a `formula-person' :)

rainer


> I don't think you need to actually substitute the x.amount/volume into
> the
> ODEs if you have the assignment rules.  In SOSlib


On Fri, 23 Jun 2006, Andrew Finney wrote:

> Folks
>
> So what your suggesting is pretty simple:
> for any SBML system always transform the system to
> create ODEs of rates of substance change
> and assignment rules that derive concentrations from substance.
>
> That's pretty straightforward I think.  I'm happy.
>
> Note:
>
> I don't think you need to actually substitute the x.amount/volume into
> the
> ODEs if you have the assignment rules.  In SOSlib
>
> x2 = x2.amount/volume
> dx1.amount/dt = k * x2
> dx2.amount/dt = ???
>
> should be equivalent to:
>
> dx1.amount/dt = k * (x2.amount/volume)
> dx2.amount/dt = ???
>
> This works because the relevant assignment rules are evaluated in the
> CVODE rhs function
> before evaluating the ODEs themselves.
>
> Or am I missing something? An issue with the jacobian???
>
> If the above isn't true then the way assignment rules work
> in the general case is wrong too.
>
> yours Andrew
>
>> -----Original Message-----
>> From: sbm...@li...
>> [mailto:sbm...@li...] On
>> Behalf Of Stefan Mueller
>> Sent: 21 June 2006 16:51
>> To: sbm...@li...
>> Subject: Re: [SOSlib-devel] implementing variable
>> compartments[Scanned]
>>
>> rainer
>>
>>> Stefan, thanks for the clarification in your last email.
>>>
>>> i think i got it now :)
>>>
>>> you wrote:
>>>> the ode for conc can be derived by differentiating x=X/V:
>>>> dx/dt = (dX/dt)/V - x*(dV/dt)/V
>>>> where dX/dt is given by the kinetic law above.
>>>
>>> dX/dt is just the sum of the +/- (stoichiometry*kineticLaw)
>>> expressions for all reactions where X is a
>> product/reactant, i.e. it
>>> is a function of concentrations x, y, z ...
>>>
>>> Right? (If not forget, the rest ...)
>>
>> right.
>>
>>> So actually, the first part of this equation (dX/dt)/V is
>> the current
>>> form of ODEs in SOSlib!
>>>
>>> Could the implementation of variable compartments in SOSlib
>> would be
>>> as easy as:
>>>
>>> 1) add the expression " - x*(dV/dt)/V "
>>> to the concentration ODEs for species in a variable compartment?
>>
>> yes.
>>
>>> 2a) if the compartment is defined by a rate rule, this rate
>> rule could
>>> be appended to all ODEs directly, i.e.
>>>
>>> newODE = currentODE - (x/V) * rateRule
>>
>> yes.
>>
>>> 2b) if the compartment is defined by an assignment rule, we
>> would have
>>> differentiate it towards time? For this we need to convert the
>>> assignment rule to a form, where differentiateAST recognizes time
>>> dependent variables that are in the assignment rule, e.g.
>> x(t), which
>>> appears only as ASTNode "x". Is this possible/easy?
>>
>> possible.
>> easy? differentiateAST has to extended.
>> there must be differentiation with respect to time, but only
>> variables for which there is an ode are differentiated.
>> (and the rhs of the ode is the result.)
>> the chain rule does the rest of the work...
>>
>>> 2c) if the compartment is changed by events, we don't need
>> to append
>>> anything but just recalculate concentrations and re-initialize the
>>> solver, just as we do now for events.
>>>
>>>
>>> If above is right - but i guess it might just not be that easy - we
>>> would have extracted two alternatives:
>>>
>>> A) use ODEs in substance/time, write assignment rules for
>> x.amount = x
>>> / volume and replace all x by x.amount in ODEs, as Andrew suggested
>>
>> you mean: x = x.amount / volume !?
>>
>>> or
>>>
>>> B) use above approach.
>>>
>>> Is that it?
>>
>> yes.
>> i vote for alternative A :)
>>
>> reason:
>> (i) in alternative B you have to do point 1 and 2a, the
>> volume correction, for each ode.
>> (ii) in alternative B you have to do point 2b, the additional
>> differentiation.
>> (iii) the use of assignment rules x = x.amount / volume are
>> not a criterion.
>> they can be used in both alternatives.
>>
>> cheers, s
>>
>>
>>> Rainer
>>> _______________________________________________
>>> sbmlsolver-devel mailing list
>>> sbm...@li...
>>> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>>
>>
>> _______________________________________________
>> sbmlsolver-devel mailing list
>> sbm...@li...
>> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>>
>