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

Re: [SOSlib-devel] variable compartment bug : correction[Scanned]

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

Rainer

you wrote:

> a) leave away the division by volume in Species_odeFromReactions
>     to get ODEs in substance/time instead of=20
> concentration/time and convert
>     all initial values to substance instead of concentration values
>=20
>=20
> b) use data->values for substance instead of concentration values
>=20
> c) calculate concentrations directly in evaluateAST:
>     the easiest way would be to further extend our AST=20
> indexing with an
>     boolean field isConcentration,
>     and a second index for the data->values field which contains the
>     the value of compartment by which this substance value=20
> must be divided
>=20

I think its too early to do this.
We need to have a rock solid understanding of the math first.

For example:

given the following SBML system:

S1 in C  /* declared with conctration units */
S1->junk : k[S1]
	/* this rate law is a function of species concentrations
returning in a rate of change of substance i.e. k has units litre per
sec */

dC/dt =3D 1

The current niave forumlation is:

[S1] =3D [S1(0)]
d[S1]/dt =3D k[S1]/C
dC/dt =3D 1

Your proposed solution I think (which should reserve the units of k) is:

S1 =3D [S1(0)] * C
dS1/dt =3D k.(S1/C) =20
	/* species amounts have to be converted back to concetrations
for the constant*/
dC/dt =3D 1

I think someone who knows needs to verify that this is correct.
I don't believe it is but I'm not qualified to comment.

>=20
> However, there might be several problems:
>=20
> *) as already pointed out by Andrew: we will have to=20
> "...  block the combination of rate rules for species in=20
> concentration=20
> units with rate rules for compartment volumes"
>=20
> i guess, the same is true for variable compartments in general, i.e.=20
> compartments changed by assignment, rate rules and by event=20
> assignments
>=20
> right?

event assignments are going to be fine in the existing scheme
but the rest are I agree problematic.

>=20
>=20
> *) One problem that I can think of now is the current=20
> `observables' implementation, i.e. that assignment rules are only=20
> calculated if the value is required for other formulae.
>=20
> The volume might however not be explicitly present in=20
> formulae and thus=20
> the `observables' code might not detect that a potential=20
> assignment rule=20
> for the volume must always be calculated. Andrew, what do you think?
>=20

I don't think there is a need to worry:

The code for constructing the minimal sets of assignment rules
is not aware of the type of variables (compartment, species or
parameter)
it is dealing with.  This
code is called after the initial set of odes and a 'maximal' set of
assignment rules have been constructed.

If you get the ODEs and 'maximal' assignment rule set right then the
code should
do the right thing.  If there is a bug in the minimization code
resist the urge to hack it so that it treats symbols differently
depending on their type.

> on the other hand, one could argue that the reaction system=20
> is formulated=20
> wrong, because a variable compartment MUST explicitly appear=20
> in kinetic=20
> laws. It is wrong to include the compartment correction into=20
> a parameter,=20
> if the compartment is variable, right? So in a correct=20
> variable-compartment model an assignment rule for a variable=20
> compartment=20
> will always be in the list of assignment rules that have to=20
> be evaluated.
>=20
> Or are there cases where this might not be true?
>=20

hmm, don't understand what you mean=20

>=20
> *) The next problem is the output of results, e.g. should=20
> cvodeResults and=20
> sbmlResults contain the substance or the concentration values?
> Should we have a function like=20
> IntegratorInstance_getVariableValueAsConcentration ?
>=20

I think its best if species are output in the units in which they
were defined on the sbml species element i.e. by default concentration
units

>=20
>=20
> *) We could make it even more complicated by allowing two ODE=20
> versions,
> i.e. calculate the ODEs in substance/time only if variable=20
> compartments=20
> appear in the model.
>=20

Yuck

>=20
> Any suggestions, opinions or comments ???
>=20

I feel out of my depth!

>=20
> Please add other problems here:
>=20
>=20

Yes, we need to check that the SBML semantic test suite has got the
right results
I can't remember if variable compartments are in the current version

yours Andrew

> -----Original Message-----
> From: sbm...@li...=20
> [mailto:sbm...@li...] On=20
> Behalf Of Rainer Machne
> Sent: 16 June 2006 16:56
> To: SOSlib Development
> Subject: Re: [SOSlib-devel] variable compartment bug :=20
> correction[Scanned]
>=20
> hi All
>=20
> the easiest way to solve the variable compartment problem=20
> without having a second data->values array might probably be to:
>=20
>=20
> a) leave away the division by volume in Species_odeFromReactions
>     to get ODEs in substance/time instead of=20
> concentration/time and convert
>     all initial values to substance instead of concentration values
>=20
>=20
> b) use data->values for substance instead of concentration values
>=20
> c) calculate concentrations directly in evaluateAST:
>     the easiest way would be to further extend our AST=20
> indexing with an
>     boolean field isConcentration,
>     and a second index for the data->values field which contains the
>     the value of compartment by which this substance value=20
> must be divided
>=20
>=20
> However, there might be several problems:
>=20
> *) as already pointed out by Andrew: we will have to=20
> "...  block the combination of rate rules for species in=20
> concentration=20
> units with rate rules for compartment volumes"
>=20
> i guess, the same is true for variable compartments in general, i.e.=20
> compartments changed by assignment, rate rules and by event=20
> assignments
>=20
> right?
>=20
>=20
> *) One problem that I can think of now is the current=20
> `observables' implementation, i.e. that assignment rules are only=20
> calculated if the value is required for other formulae.
>=20
> The volume might however not be explicitly present in=20
> formulae and thus=20
> the `observables' code might not detect that a potential=20
> assignment rule=20
> for the volume must always be calculated. Andrew, what do you think?
>=20
> on the other hand, one could argue that the reaction system=20
> is formulated=20
> wrong, because a variable compartment MUST explicitly appear=20
> in kinetic=20
> laws. It is wrong to include the compartment correction into=20
> a parameter,=20
> if the compartment is variable, right? So in a correct=20
> variable-compartment model an assignment rule for a variable=20
> compartment=20
> will always be in the list of assignment rules that have to=20
> be evaluated.
>=20
> Or are there cases where this might not be true?
>=20
>=20
> *) The next problem is the output of results, e.g. should=20
> cvodeResults and=20
> sbmlResults contain the substance or the concentration values?
> Should we have a function like=20
> IntegratorInstance_getVariableValueAsConcentration ?
>=20
>=20
>=20
> *) We could make it even more complicated by allowing two ODE=20
> versions,
> i.e. calculate the ODEs in substance/time only if variable=20
> compartments=20
> appear in the model.
>=20
>=20
> Any suggestions, opinions or comments ???
>=20
>=20
> Please add other problems here:
>=20
>=20
> Rainer
>=20
>=20
> On Wed, 14 Jun 2006, Rainer Machne wrote:
>=20
> > Stefan
> >
> >
> >> dX/dt =3D fX() / V0 * V
> >> that's all!
> >> of course, via fX the concs enter the odes for substances.
> >
> >
> > That means we would divide the ODE by the initial volume=20
> and multiply
> > again by the current volume?
> >
> > Why that? Why can't be just leave the volumes away?
> >
> > How to account for different volumes in one ODE, which happens for
> > multiple compartment and species involved in transport reactions?
> >
> > e.g. if
> > compartment V1 contains A; in substance units, with conc.=20
> A/V1 =3D [A] =3D a
> > compartment V2 contains B and C
> >
> > A->B, would be the transport reaction with a kinetic law:  kt*a*V1
> >
> > B->C, is an irreversible conversion with kinetic law: kf*b*V2
> >
> > then our concentration ODE would be
> >
> > db/dt =3D (kt*a*V1 - kf*b*V2) / V2
> >
> > right?
> >
> > Can't we just leave away the last / V2 to have the correct=20
> substance ODE?
> >
> > dB/dt =3D kt*a*V1 - kf*b*V2
> >
> > where V1 and V2 can be variable?
> >
> > Rainer
> >
> >
> > On Wed, 14 Jun 2006, Stefan Mueller wrote:
> >
> >> andrew, lukas, rainer!
> >>
> >> sorry guys, the problem of compartments is so difficult :)
> >> that i made an error, too.
> >>
> >> given the law for concentrations dx/dt =3D k*y*z for a fixed=20
> volume V,
> >> the "law" for substances X=3Dx*V is correct even for a=20
> time-dependent volume:
> >> dX/dt =3D (k*V)*y*z =3D (k/V)*Y*Z
> >> whereas the law for concentrations has to be corrected:
> >> dx/dt =3D k*y*z - x (dV/dt) / V
> >>
> >> if we write down odes for substances instead of concs, we=20
> can calculate V
> >> either by an ode or by an assignment rule.
> >> if we used odes for concs this would be more complicated.
> >>
> >> so with the sbml definition of a kinetic law for a fixed volume V0
> >> dX/dt_V0 =3D V0*dx/dt =3D V0*k*x*y =3D fX(concs)
> >> the odes for substances can be written as:
> >> dX/dt =3D fX() / V0 * V
> >> that's all!
> >> of course, via fX the concs enter the odes for substances.
> >>
> >> so. i hope that was the last error.
> >> anyway, let's discuss it on friday!
> >>
> >> cheers,
> >> stefan.
> >>
> >>
> >> Am Dienstag 13 Juni 2006 19:01 schrieb Stefan Mueller:
> >>> andrew, lukas, rainer!
> >>>
> >>> the problem of compartments (multiple or even variable)=20
> is not that easy.
> >>>
> >>> the definition of kinetic laws in sbml is conceptionally bad.
> >>> ok. the sbml people wanted to ease the treatment of=20
> multiple compartments.
> >>> and it's working...
> >>> but among other things, it complicates the treatment of variable
> >>> compartments. anyway, we can "work around" the current=20
> definition. (see
> >>> below.)
> >>>
> >>> first, how should it be:
> >>> in chemistry, rate laws are defined for concs,
> >>> e.g. dx/dt=3Dk*x*y.
> >>> and there is a reason for this: the law is independent of=20
> the volume V!
> >>> if you formulate "laws" for substances X=3Dx*V,
> >>> you get dX/dt=3D(k*V)*x*y=3D(k/V)*X*Y.
> >>> this is not a law of chemistry, but depends also on the volume V.
> >>> moreover, for time-dependent V the above "law" is wrong!
> >>>
> >>> having this in mind (?), sbml people specified dX/dt for=20
> a given volume V0,
> >>> let's call it dX/dt_V0=3D(k*V0)*x*y.
> >>> by simple calculus, we can derive dX/dt from X=3Dx*V:
> >>> ----------------------------------------------------
> >>> dX/dt =3D dX/dt_V0 / V0 * V + X * dV/dt / V
> >>> ----------------------------------------------------
> >>> dV/dt can be given explicitly or derived (!) from an=20
> assignment rule.
> >>> as rainer already suspected, we have to use odes for=20
> substances to allow
> >>> for variable compartments. (although the kinetic laws=20
> still depend on
> >>> concs).
> >>>
> >>> i hope i clarified the situation a little bit.
> >>>
> >>> cheers,
> >>> stefan.
> >>>
> >>> Am Dienstag 13 Juni 2006 15:25 schrieb Andrew Finney:
> >>>> Rainer
> >>>>
> >>>> Slow down!!
> >>>>
> >>>> I don't actually understand the argument:
> >>>> why can't you have the ODEs as ODEs of concentrations:
> >>>>
> >>>> if S1 is in a compartment with volume C then
> >>>>
> >>>> d[S1]/dt =3D (f1() + f2() + ... fn()) / C
> >>>>
> >>>> f1..fn are the reaction rates which are
> >>>> expressions that have units substance/time
> >>>>
> >>>> f1...fn are functions of the concentrations of the
> >>>> species [S1]..[Sn]
> >>>>
> >>>> I thought that's what we'd implemented.
> >>>>
> >>>> Why do you need two sets of values?
> >>>>
> >>>> I would strongly urge we go for the approach is having
> >>>> one set of values and carefully converting the units as=20
> is appropriate.
> >>>>
> >>>> fundamentally what's the problem?
> >>>>
> >>>> In the SBML you sent the only fly in the ointment
> >>>> is that the initial value for the species is
> >>>> expressed in substance units via the initialAmount=20
> attribute rather than
> >>>> the initialConcentration
> >>>> attribute which is in concentration units.
> >>>>
> >>>> All you need to do is ensure that the initialAmount
> >>>> values are used to calculate the initialConcentration=20
> values again by
> >>>> dividing by the volume.  Have
> >>>> we implemented that?
> >>>>
> >>>> Note the initial volume of the compartment is not=20
> specified in the xml.
> >>>>
> >>>> yours Andrew
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: sbm...@li...
> >>>>> [mailto:sbm...@li...] On
> >>>>> Behalf Of Rainer Machne
> >>>>> Sent: 13 June 2006 11:42
> >>>>> To: SOSlib Development
> >>>>> Subject: [SOSlib-devel] variable compartment bug[Scanned]
> >>>>>
> >>>>> Folks
> >>>>>
> >>>>> Lukas has identified another serious bug!
> >>>>>
> >>>>> SOSlib doesn't support variable compartments.
> >>>>>
> >>>>> We initialize sundials with ODEs for concentrations d[A]/dt,
> >>>>> and sundials calculates [A] + (d[A]/dt)*h, where h is a small
> >>>>> time step and [A] is the initial condition or the current value.
> >>>>>
> >>>>> If we have a variable, e.g time-dependent compartment, then
> >>>>> d[A]/dt will change with changing compartment because the
> >>>>> compartment size is part of the right hand side.
> >>>>>
> >>>>> However, not only d[A]/dt is dependent on the volume, but
> >>>>> also [A], i.e.
> >>>>> the current value in data->value!
> >>>>>
> >>>>> The attached example file exemplifies this.
> >>>>>
> >>>>> So we actually should use an ODE system in amount/time
> >>>>> instead of concentration/time, and have a second data->value
> >>>>> array for concentrations to be used in formula evaluation.
> >>>>>
> >>>>> Didn't we discuss this once? I remember that I had started to
> >>>>> do this (ODEs in amount/time), but then it got more
> >>>>> complicated then I thought and something else came up.
> >>>>>
> >>>>> Can you think of any problems we will run into? Andrew, how
> >>>>> about the compiling version?
> >>>>>
> >>>>> 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
> >>
> >
> >
> > _______________________________________________
> > sbmlsolver-devel mailing list
> > sbm...@li...
> > https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
> >
>=20
>=20
> _______________________________________________
> sbmlsolver-devel mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>=20

Re: [SOSlib-devel] variable compartment bug : correction

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

hi All

the easiest way to solve the variable compartment problem without 
having a second data->values array might probably be to:


a) leave away the division by volume in Species_odeFromReactions
    to get ODEs in substance/time instead of concentration/time and convert
    all initial values to substance instead of concentration values


b) use data->values for substance instead of concentration values

c) calculate concentrations directly in evaluateAST:
    the easiest way would be to further extend our AST indexing with an
    boolean field isConcentration,
    and a second index for the data->values field which contains the
    the value of compartment by which this substance value must be divided


However, there might be several problems:

*) as already pointed out by Andrew: we will have to 
"...  block the combination of rate rules for species in concentration 
units with rate rules for compartment volumes"

i guess, the same is true for variable compartments in general, i.e. 
compartments changed by assignment, rate rules and by event assignments

right?


*) One problem that I can think of now is the current 
`observables' implementation, i.e. that assignment rules are only 
calculated if the value is required for other formulae.

The volume might however not be explicitly present in formulae and thus 
the `observables' code might not detect that a potential assignment rule 
for the volume must always be calculated. Andrew, what do you think?

on the other hand, one could argue that the reaction system is formulated 
wrong, because a variable compartment MUST explicitly appear in kinetic 
laws. It is wrong to include the compartment correction into a parameter, 
if the compartment is variable, right? So in a correct 
variable-compartment model an assignment rule for a variable compartment 
will always be in the list of assignment rules that have to be evaluated.

Or are there cases where this might not be true?


*) The next problem is the output of results, e.g. should cvodeResults and 
sbmlResults contain the substance or the concentration values?
Should we have a function like 
IntegratorInstance_getVariableValueAsConcentration ?



*) We could make it even more complicated by allowing two ODE versions,
i.e. calculate the ODEs in substance/time only if variable compartments 
appear in the model.


Any suggestions, opinions or comments ???


Please add other problems here:


Rainer


On Wed, 14 Jun 2006, Rainer Machne wrote:

> Stefan
>
>
>> dX/dt = fX() / V0 * V
>> that's all!
>> of course, via fX the concs enter the odes for substances.
>
>
> That means we would divide the ODE by the initial volume and multiply
> again by the current volume?
>
> Why that? Why can't be just leave the volumes away?
>
> How to account for different volumes in one ODE, which happens for
> multiple compartment and species involved in transport reactions?
>
> e.g. if
> compartment V1 contains A; in substance units, with conc. A/V1 = [A] = a
> compartment V2 contains B and C
>
> A->B, would be the transport reaction with a kinetic law:  kt*a*V1
>
> B->C, is an irreversible conversion with kinetic law: kf*b*V2
>
> then our concentration ODE would be
>
> db/dt = (kt*a*V1 - kf*b*V2) / V2
>
> right?
>
> Can't we just leave away the last / V2 to have the correct substance ODE?
>
> dB/dt = kt*a*V1 - kf*b*V2
>
> where V1 and V2 can be variable?
>
> Rainer
>
>
> On Wed, 14 Jun 2006, Stefan Mueller wrote:
>
>> andrew, lukas, rainer!
>>
>> sorry guys, the problem of compartments is so difficult :)
>> that i made an error, too.
>>
>> given the law for concentrations dx/dt = k*y*z for a fixed volume V,
>> the "law" for substances X=x*V is correct even for a time-dependent volume:
>> dX/dt = (k*V)*y*z = (k/V)*Y*Z
>> whereas the law for concentrations has to be corrected:
>> dx/dt = k*y*z - x (dV/dt) / V
>>
>> if we write down odes for substances instead of concs, we can calculate V
>> either by an ode or by an assignment rule.
>> if we used odes for concs this would be more complicated.
>>
>> so with the sbml definition of a kinetic law for a fixed volume V0
>> dX/dt_V0 = V0*dx/dt = V0*k*x*y = fX(concs)
>> the odes for substances can be written as:
>> dX/dt = fX() / V0 * V
>> that's all!
>> of course, via fX the concs enter the odes for substances.
>>
>> so. i hope that was the last error.
>> anyway, let's discuss it on friday!
>>
>> cheers,
>> stefan.
>>
>>
>> Am Dienstag 13 Juni 2006 19:01 schrieb Stefan Mueller:
>>> andrew, lukas, rainer!
>>>
>>> the problem of compartments (multiple or even variable) is not that easy.
>>>
>>> the definition of kinetic laws in sbml is conceptionally bad.
>>> ok. the sbml people wanted to ease the treatment of multiple compartments.
>>> and it's working...
>>> but among other things, it complicates the treatment of variable
>>> compartments. anyway, we can "work around" the current definition. (see
>>> below.)
>>>
>>> first, how should it be:
>>> in chemistry, rate laws are defined for concs,
>>> e.g. dx/dt=k*x*y.
>>> and there is a reason for this: the law is independent of the volume V!
>>> if you formulate "laws" for substances X=x*V,
>>> you get dX/dt=(k*V)*x*y=(k/V)*X*Y.
>>> this is not a law of chemistry, but depends also on the volume V.
>>> moreover, for time-dependent V the above "law" is wrong!
>>>
>>> having this in mind (?), sbml people specified dX/dt for a given volume V0,
>>> let's call it dX/dt_V0=(k*V0)*x*y.
>>> by simple calculus, we can derive dX/dt from X=x*V:
>>> ----------------------------------------------------
>>> dX/dt = dX/dt_V0 / V0 * V + X * dV/dt / V
>>> ----------------------------------------------------
>>> dV/dt can be given explicitly or derived (!) from an assignment rule.
>>> as rainer already suspected, we have to use odes for substances to allow
>>> for variable compartments. (although the kinetic laws still depend on
>>> concs).
>>>
>>> i hope i clarified the situation a little bit.
>>>
>>> cheers,
>>> stefan.
>>>
>>> Am Dienstag 13 Juni 2006 15:25 schrieb Andrew Finney:
>>>> Rainer
>>>>
>>>> Slow down!!
>>>>
>>>> I don't actually understand the argument:
>>>> why can't you have the ODEs as ODEs of concentrations:
>>>>
>>>> if S1 is in a compartment with volume C then
>>>>
>>>> d[S1]/dt = (f1() + f2() + ... fn()) / C
>>>>
>>>> f1..fn are the reaction rates which are
>>>> expressions that have units substance/time
>>>>
>>>> f1...fn are functions of the concentrations of the
>>>> species [S1]..[Sn]
>>>>
>>>> I thought that's what we'd implemented.
>>>>
>>>> Why do you need two sets of values?
>>>>
>>>> I would strongly urge we go for the approach is having
>>>> one set of values and carefully converting the units as is appropriate.
>>>>
>>>> fundamentally what's the problem?
>>>>
>>>> In the SBML you sent the only fly in the ointment
>>>> is that the initial value for the species is
>>>> expressed in substance units via the initialAmount attribute rather than
>>>> the initialConcentration
>>>> attribute which is in concentration units.
>>>>
>>>> All you need to do is ensure that the initialAmount
>>>> values are used to calculate the initialConcentration values again by
>>>> dividing by the volume.  Have
>>>> we implemented that?
>>>>
>>>> Note the initial volume of the compartment is not specified in the xml.
>>>>
>>>> yours Andrew
>>>>
>>>>> -----Original Message-----
>>>>> From: sbm...@li...
>>>>> [mailto:sbm...@li...] On
>>>>> Behalf Of Rainer Machne
>>>>> Sent: 13 June 2006 11:42
>>>>> To: SOSlib Development
>>>>> Subject: [SOSlib-devel] variable compartment bug[Scanned]
>>>>>
>>>>> Folks
>>>>>
>>>>> Lukas has identified another serious bug!
>>>>>
>>>>> SOSlib doesn't support variable compartments.
>>>>>
>>>>> We initialize sundials with ODEs for concentrations d[A]/dt,
>>>>> and sundials calculates [A] + (d[A]/dt)*h, where h is a small
>>>>> time step and [A] is the initial condition or the current value.
>>>>>
>>>>> If we have a variable, e.g time-dependent compartment, then
>>>>> d[A]/dt will change with changing compartment because the
>>>>> compartment size is part of the right hand side.
>>>>>
>>>>> However, not only d[A]/dt is dependent on the volume, but
>>>>> also [A], i.e.
>>>>> the current value in data->value!
>>>>>
>>>>> The attached example file exemplifies this.
>>>>>
>>>>> So we actually should use an ODE system in amount/time
>>>>> instead of concentration/time, and have a second data->value
>>>>> array for concentrations to be used in formula evaluation.
>>>>>
>>>>> Didn't we discuss this once? I remember that I had started to
>>>>> do this (ODEs in amount/time), but then it got more
>>>>> complicated then I thought and something else came up.
>>>>>
>>>>> Can you think of any problems we will run into? Andrew, how
>>>>> about the compiling version?
>>>>>
>>>>> 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
>>
>
>
> _______________________________________________
> sbmlsolver-devel mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>

[SOSlib-devel] piecewise evaluation and abs differentiation

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

hi

just for the record, and if someone is interested:

i have just commited a new processAST.c file

a) repaired and generalized piecewise evaluation:

a1) piecewise for the simple piece/otherwise case was implemented wrong
a2) a general solution for multiple pieces w or w/o otherwise statements

I have added the new code for piecewise evaluation below, in case 
someone finds the time to check this.


b) repaired differentiation of abs function:

f(x) = abs(a(x))
df/dx = sig(a(x)) * da/dx

we have decided to set sig(a(x)) to 0 if a(x) = 0, i.e. sig(0) = 0,
even though the signum function is actually not defined at 0.

Alternatively we could either set sig(0) to +1
or forget about differentiation of abs and use CVODE's internal 
approximation instead.

Any opinions?

Rainer



   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;

Re: [SOSlib-devel] MathML Piecewise function[Scanned]

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

I can't really find a nice description of piecewise. There are only two 
examples, one is the simple case piece/otherwise:

  piecewise(0, lt(x, 0), x)

the other one is the case with three pieces:

  piecewise(-x, lt(x, 0), 0, eq(x, 0), x, gt(x, 0))

(which is a definition of abs(x)).

Can there also be cases with e.g. two pieces and one otherwise?
Or only two pieces?

Can the following distinction:

* odd number of AST children indicates that the last expression is an 
otherwise expression

* even number of AST children indicates that all children a pairs of 
pieces

solve it generally or are there other cases?

Rainer

On Fri, 16 Jun 2006, Rainer Machne wrote:

>
>> You are right this is a bug in the test suite
>
> Ok. We have implemented this bug in SOSlib :)
>
> i guess i have done the piecewise function when going through the tests
> and used these examples as a template for implementation :)
>
> r
>
>
> On Fri, 16 Jun 2006, Andrew Finney wrote:
>
>> Rainer
>>
>> You are right this is a bug in the test suite
>>
>> Andrew
>>
>>> -----Original Message-----
>>> From: Rainer Machne [mailto:ra...@tb...]
>>> Sent: 16 June 2006 12:23
>>> To: Andrew Finney
>>> Cc: SOSlib Development
>>> Subject: MathML Piecewise function[Scanned]
>>>
>>> hi Andrew,
>>>
>>> The use of piecewise in the semantic test suite seems to
>>> differ from official definitions:
>>>
>>> E.g. in discontinuityTimeAndDelay-geq-l2.xml
>>> it's:
>>>
>>>   <piecewise>
>>>     <piece>
>>>       <apply>
>>>         <geq/>
>>>         <ci> s2 </ci>
>>>         <cn> 4 </cn>
>>>       </apply>
>>>       <cn>1.5</cn>
>>>     </piece>
>>>     <otherwise>
>>>        <cn>0.05</cn>
>>>     </otherwise>
>>> </piecewise>
>>>
>>> which is
>>>
>>> piecewise(geq(s2, 4), 1.5, 0.05)
>>>
>>> in libSBML infix and interpreted as
>>>
>>> 1.5 if s2 >= 4
>>> and
>>> 0.05 otherwise
>>>
>>> by SOSlib.
>>> SOSlib produces the results required by the testsuite.
>>>
>>>
>>> However, at
>>> http://www.w3.org/TR/MathML2/chapter4.html#contm.piecewise
>>> the definition is slightly different:
>>>
>>> <piecewise>
>>>    <piece>
>>>        <cn> 0 </cn>
>>>        <apply><lt/><ci> x </ci> <cn> 0 </cn></apply>
>>>    </piece>
>>>    <otherwise>
>>>        <ci> x </ci>
>>>    </otherwise>
>>> </piecewise>
>>>
>>> in libSBML infix
>>> piecewise(0, lt(x, 0), x)
>>>
>>> interpreted as
>>> 0 if x < 0
>>> and x otherwise.
>>>
>>> Note, that the if condition of the piece element is BEFORE
>>> the associated result, while it is AFTER the result in the
>>> test suite example.
>>>
>>> The same ordering is found in the piecewise example for more
>>> pieces - see below. The result associated with a piece is
>>> always BEFORE the condition.
>>>
>>> Am i missing something or is the test suite example (and
>>> SOSlib) wrong?
>>>
>>> Rainer
>>>
>>>
>>>
>>> The general example with more pieces:
>>>
>>> <piecewise>
>>>    <piece>
>>>        <apply><minus/><ci> x </ci></apply>
>>>        <apply><lt/><ci> x </ci> <cn> 0 </cn></apply>
>>>    </piece>
>>>    <piece>
>>>        <cn> 0 </cn>
>>>        <apply><eq/><ci> x </ci> <cn> 0 </cn></apply>
>>>    </piece>
>>>    <piece>
>>>        <ci> x </ci>
>>>        <apply><gt/><ci> x </ci> <cn> 0 </cn></apply>
>>>    </piece>
>>> </piecewise>
>>>
>>
>
>
> _______________________________________________
> sbmlsolver-devel mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>

Re: [SOSlib-devel] MathML Piecewise function[Scanned]

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

> You are right this is a bug in the test suite

Ok. We have implemented this bug in SOSlib :)

i guess i have done the piecewise function when going through the tests 
and used these examples as a template for implementation :)

r


On Fri, 16 Jun 2006, Andrew Finney wrote:

> Rainer
>
> You are right this is a bug in the test suite
>
> Andrew
>
>> -----Original Message-----
>> From: Rainer Machne [mailto:ra...@tb...]
>> Sent: 16 June 2006 12:23
>> To: Andrew Finney
>> Cc: SOSlib Development
>> Subject: MathML Piecewise function[Scanned]
>>
>> hi Andrew,
>>
>> The use of piecewise in the semantic test suite seems to
>> differ from official definitions:
>>
>> E.g. in discontinuityTimeAndDelay-geq-l2.xml
>> it's:
>>
>>   <piecewise>
>>     <piece>
>>       <apply>
>>         <geq/>
>>         <ci> s2 </ci>
>>         <cn> 4 </cn>
>>       </apply>
>>       <cn>1.5</cn>
>>     </piece>
>>     <otherwise>
>>        <cn>0.05</cn>
>>     </otherwise>
>> </piecewise>
>>
>> which is
>>
>> piecewise(geq(s2, 4), 1.5, 0.05)
>>
>> in libSBML infix and interpreted as
>>
>> 1.5 if s2 >= 4
>> and
>> 0.05 otherwise
>>
>> by SOSlib.
>> SOSlib produces the results required by the testsuite.
>>
>>
>> However, at
>> http://www.w3.org/TR/MathML2/chapter4.html#contm.piecewise
>> the definition is slightly different:
>>
>> <piecewise>
>>    <piece>
>>        <cn> 0 </cn>
>>        <apply><lt/><ci> x </ci> <cn> 0 </cn></apply>
>>    </piece>
>>    <otherwise>
>>        <ci> x </ci>
>>    </otherwise>
>> </piecewise>
>>
>> in libSBML infix
>> piecewise(0, lt(x, 0), x)
>>
>> interpreted as
>> 0 if x < 0
>> and x otherwise.
>>
>> Note, that the if condition of the piece element is BEFORE
>> the associated result, while it is AFTER the result in the
>> test suite example.
>>
>> The same ordering is found in the piecewise example for more
>> pieces - see below. The result associated with a piece is
>> always BEFORE the condition.
>>
>> Am i missing something or is the test suite example (and
>> SOSlib) wrong?
>>
>> Rainer
>>
>>
>>
>> The general example with more pieces:
>>
>> <piecewise>
>>    <piece>
>>        <apply><minus/><ci> x </ci></apply>
>>        <apply><lt/><ci> x </ci> <cn> 0 </cn></apply>
>>    </piece>
>>    <piece>
>>        <cn> 0 </cn>
>>        <apply><eq/><ci> x </ci> <cn> 0 </cn></apply>
>>    </piece>
>>    <piece>
>>        <ci> x </ci>
>>        <apply><gt/><ci> x </ci> <cn> 0 </cn></apply>
>>    </piece>
>> </piecewise>
>>
>

Re: [SOSlib-devel] MathML Piecewise function[Scanned]

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

Rainer

You are right this is a bug in the test suite

Andrew=20

> -----Original Message-----
> From: Rainer Machne [mailto:ra...@tb...]=20
> Sent: 16 June 2006 12:23
> To: Andrew Finney
> Cc: SOSlib Development
> Subject: MathML Piecewise function[Scanned]
>=20
> hi Andrew,
>=20
> The use of piecewise in the semantic test suite seems to=20
> differ from official definitions:
>=20
> E.g. in discontinuityTimeAndDelay-geq-l2.xml
> it's:
>=20
>   <piecewise>
>     <piece>
>       <apply>
>         <geq/>
>         <ci> s2 </ci>
>         <cn> 4 </cn>
>       </apply>
>       <cn>1.5</cn>
>     </piece>
>     <otherwise>
>        <cn>0.05</cn>
>     </otherwise>
> </piecewise>
>=20
> which is
>=20
> piecewise(geq(s2, 4), 1.5, 0.05)
>=20
> in libSBML infix and interpreted as
>=20
> 1.5 if s2 >=3D 4
> and
> 0.05 otherwise
>=20
> by SOSlib.
> SOSlib produces the results required by the testsuite.
>=20
>=20
> However, at
> http://www.w3.org/TR/MathML2/chapter4.html#contm.piecewise
> the definition is slightly different:
>=20
> <piecewise>
>    <piece>
>        <cn> 0 </cn>
>        <apply><lt/><ci> x </ci> <cn> 0 </cn></apply>
>    </piece>
>    <otherwise>
>        <ci> x </ci>
>    </otherwise>
> </piecewise>
>=20
> in libSBML infix
> piecewise(0, lt(x, 0), x)
>=20
> interpreted as
> 0 if x < 0
> and x otherwise.
>=20
> Note, that the if condition of the piece element is BEFORE=20
> the associated result, while it is AFTER the result in the=20
> test suite example.
>=20
> The same ordering is found in the piecewise example for more=20
> pieces - see below. The result associated with a piece is=20
> always BEFORE the condition.
>=20
> Am i missing something or is the test suite example (and=20
> SOSlib) wrong?
>=20
> Rainer
>=20
>=20
>=20
> The general example with more pieces:
>=20
> <piecewise>
>    <piece>
>        <apply><minus/><ci> x </ci></apply>
>        <apply><lt/><ci> x </ci> <cn> 0 </cn></apply>
>    </piece>
>    <piece>
>        <cn> 0 </cn>
>        <apply><eq/><ci> x </ci> <cn> 0 </cn></apply>
>    </piece>
>    <piece>
>        <ci> x </ci>
>        <apply><gt/><ci> x </ci> <cn> 0 </cn></apply>
>    </piece>
> </piecewise>
>=20

[SOSlib-devel] MathML Piecewise function

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

hi Andrew,

The use of piecewise in the semantic test suite seems to differ from 
official definitions:

E.g. in discontinuityTimeAndDelay-geq-l2.xml
it's:

  <piecewise>
    <piece>
      <apply>
        <geq/>
        <ci> s2 </ci>
        <cn> 4 </cn>
      </apply>
      <cn>1.5</cn>
    </piece>
    <otherwise>
       <cn>0.05</cn>
    </otherwise>
</piecewise>

which is

piecewise(geq(s2, 4), 1.5, 0.05)

in libSBML infix and interpreted as

1.5 if s2 >= 4
and
0.05 otherwise

by SOSlib.
SOSlib produces the results required by the testsuite.


However, at
http://www.w3.org/TR/MathML2/chapter4.html#contm.piecewise
the definition is slightly different:

<piecewise>
   <piece>
       <cn> 0 </cn>
       <apply><lt/><ci> x </ci> <cn> 0 </cn></apply>
   </piece>
   <otherwise>
       <ci> x </ci>
   </otherwise>
</piecewise>

in libSBML infix
piecewise(0, lt(x, 0), x)

interpreted as
0 if x < 0
and x otherwise.

Note, that the if condition of the piece element is BEFORE the 
associated result, while it is AFTER the result in the test suite example.

The same ordering is found in the piecewise example for more pieces - see 
below. The result associated with a piece is always BEFORE the condition.

Am i missing something or is the test suite example (and SOSlib) wrong?

Rainer



The general example with more pieces:

<piecewise>
   <piece>
       <apply><minus/><ci> x </ci></apply>
       <apply><lt/><ci> x </ci> <cn> 0 </cn></apply>
   </piece>
   <piece>
       <cn> 0 </cn>
       <apply><eq/><ci> x </ci> <cn> 0 </cn></apply>
   </piece>
   <piece>
       <ci> x </ci>
       <apply><gt/><ci> x </ci> <cn> 0 </cn></apply>
   </piece>
</piecewise>

Re: [SOSlib-devel] internal headers may need to be in the installation for dynamic compilation + RE: AIX built + dynamic compilation using gcc + help required[Scanned]

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

Rainer

I can't really comment on this stuff I'm only going on what I read in
the autoconf pdf

I don't think affects library searches I think its just about what you
can and cannot have as #define in config.h

I don't think it matters very much

yours Andrew=20

> -----Original Message-----
> From: Rainer Machne [mailto:ra...@tb...]=20
> Sent: 14 June 2006 18:41
> To: Andrew Finney
> Cc: SOSlib Development
> Subject: Re: [SOSlib-devel] internal headers may need to be=20
> in the installation for dynamic compilation + RE: AIX built +=20
> dynamic compilation using gcc + help required[Scanned]
>=20
> Andrew
>=20
>=20
> > Actually using AC_DEFINE and inserting hardcoded directories into=20
> > config.h is against GNU coding standards
>=20
> But the values of these variables (SUNDIALS_CFLAGS etc) are=20
> not hardcoded but actually passed via the commandline=20
> arguments to configure
>=20
> ./configure -prefix=3DSOSLIB_INSTALL =
--with-sundials=3DSUNDIALS_INSTALL
>=20
> or automatically set by the search for specific headers in
> config/sundials.m4 in various default directories, e.g. /usr/local
>=20
> Am i missing something here?
> Are our library searches in the m4 file against GNU coding standards?
>=20
> Rainer
>=20
>=20
>=20
> On Wed, 14 Jun 2006, Andrew Finney wrote:
>=20
> > Rainer
> >
> > Be aware that some of the 'internal' headers containing structure=20
> > definitions will need to be put into the installation so that the=20
> > dynamic compilation can reach it.
> >
> > On the build stuff
> >
> > Actually using AC_DEFINE and inserting hardcoded directories into=20
> > config.h is against GNU coding standards (I assume there is some=20
> > subtlty I can't think of!) according to the automake and=20
> autoconf pdfs
> >
> > So I plan to add
> >
> > SUNDIALS_CFLAGS=3D"-I$with_sundials/include
> > -DSUNDIALS_INCLUDE=3D$with_sundials/include
> > -DSOSLIB_INCLUDE=3D$(includedir)"
> >
> > etc
> >
> > to config/sundials.m4
> >
> > I'll try it tomorrow
> >
> > yours Andrew
> >
> >> -----Original Message-----
> >> From: Rainer Machne [mailto:ra...@tb...]
> >> Sent: 14 June 2006 17:54
> >> To: Andrew Finney
> >> Cc: SOSlib Development
> >> Subject: Re: [SOSlib-devel] AIX built + dynamic=20
> compilation using gcc=20
> >> + help required[Scanned]
> >>
> >> Andrew
> >>
> >> great news!
> >>
> >>
> >>> Is there a way to have something like:
> >>>
> >>> #define SUNDIALS_INSTALLATION "/usr/local/"
> >>> #define SOSLIB_INSTALLATION "/usr/home/finney"
> >>
> >> i guess, all we need to do is add some lines like
> >>
> >>    AC_DEFINE([USE_SUNDIALS_SUNDIALS], 1,
> >>              [Define to 1 to use the SUNDIALS Library])
> >>
> >> to the config/sundials.m4 file using the existing variables=20
> >> $SUNDIALS_CFLAGS, $SUNDIALS_LDFLAGS and $SUNDIALS_LIBS that we=20
> >> discussed earlier. Their value is printed as the final=20
> output of the=20
> >> configure process. They already contain the -L and -I switches.
> >>
> >> The $prefix variable should contain the SOSlib installation path.
> >>
> >> Maybe these variables could be used directly and you only=20
> need to add=20
> >> the following lines to config/sundials.m4
> >>
> >>    AC_DEFINE([SUNDIALS_CFLAGS], $SUNDIALS_CFLAGS,
> >>              [SUNDIALS include directory])
> >>    AC_DEFINE([SUNDIALS_LDFLAGS], $SUNDIALS_LDFLAGS,
> >>              [SUNDIALS lib directory])
> >>    AC_DEFINE([SUNDIALS_LIBS], $SUNDIALS_LIBS,
> >>              [SUNDIALS lib switches])
> >>
> >> If we don't want the -L, -I, or the specific include and lib=20
> >> subdirectories we could use sed to remove these and define new=20
> >> variables.
> >>
> >> For SOSlib directories, the line
> >>
> >>    AC_DEFINE([SOSLIB_INSTALLATION], $prefix,
> >>              [SSOSlib install directory])
> >>
> >> should be in the configure.in file.
> >>
> >> I think that should do it, but i am also not an expert on this.
> >>
> >> Xtof, what do you think?
> >>
> >> Rainer
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Wed, 14 Jun 2006, Andrew Finney wrote:
> >>
> >>> Rainer
> >>>
> >>> I have managed get SOSlib to build on AIX and more
> >> importantly I have
> >>> managed to implement dynamic compilation using
> >>> g++ and shared libraries the same way as I did for windows
> >> using tcc.
> >>> The performance seems to be in the same ball park as the
> >> compiled code
> >>> was achieving on windows.  I assumed that tcc is i386 specific.
> >>>
> >>> I'm effectively working on my own branch as I have not=20
> resolved the=20
> >>> `bug` in the most recent checked in source that's caused
> >> our model to
> >>> fail.  So I'll probably just email you the relevant source files.
> >>> I'll try to document all the hacks required to get SOSlib
> >> to build on
> >>> AIX.
> >>>
> >>> One issue:
> >>>
> >>> I need to get hold of the include directory for sundials=20
> and SOSlib=20
> >>> for the dynamic compilation, that is in the code and not in
> >> a build file.
> >>> All the files use temporary filenames
> >>>
> >>> Is there a way to have something like:
> >>>
> >>> #define SUNDIALS_INSTALLATION "/usr/local/"
> >>> #define SOSLIB_INSTALLATION "/usr/home/finney"
> >>>
> >>> or
> >>>
> >>> #define SUNDIALS_INCLUDE "/usr/local/include"
> >>> #define SOSLIB_INCLUDE "/usr/home/finney/include"
> >>>
> >>> inserted into config.h
> >>>
> >>> ?
> >>>
> >>> I assume this means some kind of configure.in hack I'm not
> >> exactly a
> >>> guru on that so guidance would be nice.
> >>>
> >>> Background:
> >>>
> >>> At the moment I have to hard code the include path which is
> >> not ideal.
> >>> I tried using the same technique as windows: locate the sos=20
> >>> shared/dynamic library and then locate the include
> >> directory relative
> >>> to that.  I ran into a showstopper on that on AIX :=20
> missing struct=20
> >>> definition in the include files.  Anyway that's not the
> >> ideal approach
> >>> using the above would be better in an open-source build=20
> to install=20
> >>> environment.
> >>>
> >>> yours Andrew
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> 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] internal headers may need to be in the installation for dynamic compilation + RE: AIX built + dynamic compilation using gcc + help required[Scanned]

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

Andrew


> Actually using AC_DEFINE and inserting hardcoded directories into
> config.h is against GNU coding standards

But the values of these variables (SUNDIALS_CFLAGS etc) are not 
hardcoded but actually passed via the commandline arguments to configure

./configure -prefix=SOSLIB_INSTALL --with-sundials=SUNDIALS_INSTALL

or automatically set by the search for specific headers in 
config/sundials.m4 in various default directories, e.g. /usr/local

Am i missing something here?
Are our library searches in the m4 file against GNU coding standards?

Rainer



On Wed, 14 Jun 2006, Andrew Finney wrote:

> Rainer
>
> Be aware that some of the 'internal' headers containing structure
> definitions will need
> to be put into the installation so that the dynamic compilation can
> reach it.
>
> On the build stuff
>
> Actually using AC_DEFINE and inserting hardcoded directories into
> config.h is against GNU coding standards
> (I assume there is some subtlty I can't think of!) according to the
> automake and autoconf pdfs
>
> So I plan to add
>
> SUNDIALS_CFLAGS="-I$with_sundials/include
> -DSUNDIALS_INCLUDE=$with_sundials/include
> -DSOSLIB_INCLUDE=$(includedir)"
>
> etc
>
> to config/sundials.m4
>
> I'll try it tomorrow
>
> yours Andrew
>
>> -----Original Message-----
>> From: Rainer Machne [mailto:ra...@tb...]
>> Sent: 14 June 2006 17:54
>> To: Andrew Finney
>> Cc: SOSlib Development
>> Subject: Re: [SOSlib-devel] AIX built + dynamic compilation
>> using gcc + help required[Scanned]
>>
>> Andrew
>>
>> great news!
>>
>>
>>> Is there a way to have something like:
>>>
>>> #define SUNDIALS_INSTALLATION "/usr/local/"
>>> #define SOSLIB_INSTALLATION "/usr/home/finney"
>>
>> i guess, all we need to do is add some lines like
>>
>>    AC_DEFINE([USE_SUNDIALS_SUNDIALS], 1,
>>              [Define to 1 to use the SUNDIALS Library])
>>
>> to the config/sundials.m4 file using the existing variables
>> $SUNDIALS_CFLAGS, $SUNDIALS_LDFLAGS and $SUNDIALS_LIBS that
>> we discussed earlier. Their value is printed as the final
>> output of the configure process. They already contain the -L
>> and -I switches.
>>
>> The $prefix variable should contain the SOSlib installation path.
>>
>> Maybe these variables could be used directly and you only
>> need to add the following lines to config/sundials.m4
>>
>>    AC_DEFINE([SUNDIALS_CFLAGS], $SUNDIALS_CFLAGS,
>>              [SUNDIALS include directory])
>>    AC_DEFINE([SUNDIALS_LDFLAGS], $SUNDIALS_LDFLAGS,
>>              [SUNDIALS lib directory])
>>    AC_DEFINE([SUNDIALS_LIBS], $SUNDIALS_LIBS,
>>              [SUNDIALS lib switches])
>>
>> If we don't want the -L, -I, or the specific include and lib
>> subdirectories we could use sed to remove these and define
>> new variables.
>>
>> For SOSlib directories, the line
>>
>>    AC_DEFINE([SOSLIB_INSTALLATION], $prefix,
>>              [SSOSlib install directory])
>>
>> should be in the configure.in file.
>>
>> I think that should do it, but i am also not an expert on this.
>>
>> Xtof, what do you think?
>>
>> Rainer
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Wed, 14 Jun 2006, Andrew Finney wrote:
>>
>>> Rainer
>>>
>>> I have managed get SOSlib to build on AIX and more
>> importantly I have
>>> managed to implement dynamic compilation using
>>> g++ and shared libraries the same way as I did for windows
>> using tcc.
>>> The performance seems to be in the same ball park as the
>> compiled code
>>> was achieving on windows.  I assumed that tcc is i386 specific.
>>>
>>> I'm effectively working on my own branch as I have not resolved the
>>> `bug` in the most recent checked in source that's caused
>> our model to
>>> fail.  So I'll probably just email you the relevant source files.
>>> I'll try to document all the hacks required to get SOSlib
>> to build on
>>> AIX.
>>>
>>> One issue:
>>>
>>> I need to get hold of the include directory for sundials and SOSlib
>>> for the dynamic compilation, that is in the code and not in
>> a build file.
>>> All the files use temporary filenames
>>>
>>> Is there a way to have something like:
>>>
>>> #define SUNDIALS_INSTALLATION "/usr/local/"
>>> #define SOSLIB_INSTALLATION "/usr/home/finney"
>>>
>>> or
>>>
>>> #define SUNDIALS_INCLUDE "/usr/local/include"
>>> #define SOSLIB_INCLUDE "/usr/home/finney/include"
>>>
>>> inserted into config.h
>>>
>>> ?
>>>
>>> I assume this means some kind of configure.in hack I'm not
>> exactly a
>>> guru on that so guidance would be nice.
>>>
>>> Background:
>>>
>>> At the moment I have to hard code the include path which is
>> not ideal.
>>> I tried using the same technique as windows: locate the sos
>>> shared/dynamic library and then locate the include
>> directory relative
>>> to that.  I ran into a showstopper on that on AIX : missing struct
>>> definition in the include files.  Anyway that's not the
>> ideal approach
>>> using the above would be better in an open-source build to install
>>> environment.
>>>
>>> yours Andrew
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>

[SOSlib-devel] internal headers may need to be in the installation for dynamic compilation + RE: AIX built + dynamic compilation using gcc + help required[Scanned]

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

Rainer

Be aware that some of the 'internal' headers containing structure
definitions will need
to be put into the installation so that the dynamic compilation can
reach it.

On the build stuff

Actually using AC_DEFINE and inserting hardcoded directories into
config.h is against GNU coding standards
(I assume there is some subtlty I can't think of!) according to the
automake and autoconf pdfs

So I plan to add =20

SUNDIALS_CFLAGS=3D"-I$with_sundials/include
-DSUNDIALS_INCLUDE=3D$with_sundials/include
-DSOSLIB_INCLUDE=3D$(includedir)"

etc

to config/sundials.m4

I'll try it tomorrow

yours Andrew

> -----Original Message-----
> From: Rainer Machne [mailto:ra...@tb...]=20
> Sent: 14 June 2006 17:54
> To: Andrew Finney
> Cc: SOSlib Development
> Subject: Re: [SOSlib-devel] AIX built + dynamic compilation=20
> using gcc + help required[Scanned]
>=20
> Andrew
>=20
> great news!
>=20
>=20
> > Is there a way to have something like:
> >
> > #define SUNDIALS_INSTALLATION "/usr/local/"
> > #define SOSLIB_INSTALLATION "/usr/home/finney"
>=20
> i guess, all we need to do is add some lines like
>=20
>    AC_DEFINE([USE_SUNDIALS_SUNDIALS], 1,
>              [Define to 1 to use the SUNDIALS Library])
>=20
> to the config/sundials.m4 file using the existing variables=20
> $SUNDIALS_CFLAGS, $SUNDIALS_LDFLAGS and $SUNDIALS_LIBS that=20
> we discussed earlier. Their value is printed as the final=20
> output of the configure process. They already contain the -L=20
> and -I switches.
>=20
> The $prefix variable should contain the SOSlib installation path.
>=20
> Maybe these variables could be used directly and you only=20
> need to add the following lines to config/sundials.m4
>=20
>    AC_DEFINE([SUNDIALS_CFLAGS], $SUNDIALS_CFLAGS,
>              [SUNDIALS include directory])
>    AC_DEFINE([SUNDIALS_LDFLAGS], $SUNDIALS_LDFLAGS,
>              [SUNDIALS lib directory])
>    AC_DEFINE([SUNDIALS_LIBS], $SUNDIALS_LIBS,
>              [SUNDIALS lib switches])
>=20
> If we don't want the -L, -I, or the specific include and lib=20
> subdirectories we could use sed to remove these and define=20
> new variables.
>=20
> For SOSlib directories, the line
>=20
>    AC_DEFINE([SOSLIB_INSTALLATION], $prefix,
>              [SSOSlib install directory])
>=20
> should be in the configure.in file.
>=20
> I think that should do it, but i am also not an expert on this.
>=20
> Xtof, what do you think?
>=20
> Rainer
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> On Wed, 14 Jun 2006, Andrew Finney wrote:
>=20
> > Rainer
> >
> > I have managed get SOSlib to build on AIX and more=20
> importantly I have=20
> > managed to implement dynamic compilation using
> > g++ and shared libraries the same way as I did for windows=20
> using tcc.
> > The performance seems to be in the same ball park as the=20
> compiled code=20
> > was achieving on windows.  I assumed that tcc is i386 specific.
> >
> > I'm effectively working on my own branch as I have not resolved the=20
> > `bug` in the most recent checked in source that's caused=20
> our model to=20
> > fail.  So I'll probably just email you the relevant source files. =20
> > I'll try to document all the hacks required to get SOSlib=20
> to build on=20
> > AIX.
> >
> > One issue:
> >
> > I need to get hold of the include directory for sundials and SOSlib=20
> > for the dynamic compilation, that is in the code and not in=20
> a build file.
> > All the files use temporary filenames
> >
> > Is there a way to have something like:
> >
> > #define SUNDIALS_INSTALLATION "/usr/local/"
> > #define SOSLIB_INSTALLATION "/usr/home/finney"
> >
> > or
> >
> > #define SUNDIALS_INCLUDE "/usr/local/include"
> > #define SOSLIB_INCLUDE "/usr/home/finney/include"
> >
> > inserted into config.h
> >
> > ?
> >
> > I assume this means some kind of configure.in hack I'm not=20
> exactly a=20
> > guru on that so guidance would be nice.
> >
> > Background:
> >
> > At the moment I have to hard code the include path which is=20
> not ideal.
> > I tried using the same technique as windows: locate the sos=20
> > shared/dynamic library and then locate the include=20
> directory relative=20
> > to that.  I ran into a showstopper on that on AIX : missing struct=20
> > definition in the include files.  Anyway that's not the=20
> ideal approach=20
> > using the above would be better in an open-source build to install=20
> > environment.
> >
> > yours Andrew
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > sbmlsolver-devel mailing list
> > sbm...@li...
> > https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
> >
>=20

Re: [SOSlib-devel] variable compartment bug : correction

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

Stefan


> dX/dt = fX() / V0 * V
> that's all!
> of course, via fX the concs enter the odes for substances.


That means we would divide the ODE by the initial volume and multiply 
again by the current volume?

Why that? Why can't be just leave the volumes away?

How to account for different volumes in one ODE, which happens for 
multiple compartment and species involved in transport reactions?

e.g. if
compartment V1 contains A; in substance units, with conc. A/V1 = [A] = a
compartment V2 contains B and C

A->B, would be the transport reaction with a kinetic law:  kt*a*V1

B->C, is an irreversible conversion with kinetic law: kf*b*V2

then our concentration ODE would be

db/dt = (kt*a*V1 - kf*b*V2) / V2

right?

Can't we just leave away the last / V2 to have the correct substance ODE?

dB/dt = kt*a*V1 - kf*b*V2

where V1 and V2 can be variable?

Rainer


On Wed, 14 Jun 2006, Stefan Mueller wrote:

> andrew, lukas, rainer!
>
> sorry guys, the problem of compartments is so difficult :)
> that i made an error, too.
>
> given the law for concentrations dx/dt = k*y*z for a fixed volume V,
> the "law" for substances X=x*V is correct even for a time-dependent volume:
> dX/dt = (k*V)*y*z = (k/V)*Y*Z
> whereas the law for concentrations has to be corrected:
> dx/dt = k*y*z - x (dV/dt) / V
>
> if we write down odes for substances instead of concs, we can calculate V
> either by an ode or by an assignment rule.
> if we used odes for concs this would be more complicated.
>
> so with the sbml definition of a kinetic law for a fixed volume V0
> dX/dt_V0 = V0*dx/dt = V0*k*x*y = fX(concs)
> the odes for substances can be written as:
> dX/dt = fX() / V0 * V
> that's all!
> of course, via fX the concs enter the odes for substances.
>
> so. i hope that was the last error.
> anyway, let's discuss it on friday!
>
> cheers,
> stefan.
>
>
> Am Dienstag 13 Juni 2006 19:01 schrieb Stefan Mueller:
>> andrew, lukas, rainer!
>>
>> the problem of compartments (multiple or even variable) is not that easy.
>>
>> the definition of kinetic laws in sbml is conceptionally bad.
>> ok. the sbml people wanted to ease the treatment of multiple compartments.
>> and it's working...
>> but among other things, it complicates the treatment of variable
>> compartments. anyway, we can "work around" the current definition. (see
>> below.)
>>
>> first, how should it be:
>> in chemistry, rate laws are defined for concs,
>> e.g. dx/dt=k*x*y.
>> and there is a reason for this: the law is independent of the volume V!
>> if you formulate "laws" for substances X=x*V,
>> you get dX/dt=(k*V)*x*y=(k/V)*X*Y.
>> this is not a law of chemistry, but depends also on the volume V.
>> moreover, for time-dependent V the above "law" is wrong!
>>
>> having this in mind (?), sbml people specified dX/dt for a given volume V0,
>> let's call it dX/dt_V0=(k*V0)*x*y.
>> by simple calculus, we can derive dX/dt from X=x*V:
>> ----------------------------------------------------
>> dX/dt = dX/dt_V0 / V0 * V + X * dV/dt / V
>> ----------------------------------------------------
>> dV/dt can be given explicitly or derived (!) from an assignment rule.
>> as rainer already suspected, we have to use odes for substances to allow
>> for variable compartments. (although the kinetic laws still depend on
>> concs).
>>
>> i hope i clarified the situation a little bit.
>>
>> cheers,
>> stefan.
>>
>> Am Dienstag 13 Juni 2006 15:25 schrieb Andrew Finney:
>>> Rainer
>>>
>>> Slow down!!
>>>
>>> I don't actually understand the argument:
>>> why can't you have the ODEs as ODEs of concentrations:
>>>
>>> if S1 is in a compartment with volume C then
>>>
>>> d[S1]/dt = (f1() + f2() + ... fn()) / C
>>>
>>> f1..fn are the reaction rates which are
>>> expressions that have units substance/time
>>>
>>> f1...fn are functions of the concentrations of the
>>> species [S1]..[Sn]
>>>
>>> I thought that's what we'd implemented.
>>>
>>> Why do you need two sets of values?
>>>
>>> I would strongly urge we go for the approach is having
>>> one set of values and carefully converting the units as is appropriate.
>>>
>>> fundamentally what's the problem?
>>>
>>> In the SBML you sent the only fly in the ointment
>>> is that the initial value for the species is
>>> expressed in substance units via the initialAmount attribute rather than
>>> the initialConcentration
>>> attribute which is in concentration units.
>>>
>>> All you need to do is ensure that the initialAmount
>>> values are used to calculate the initialConcentration values again by
>>> dividing by the volume.  Have
>>> we implemented that?
>>>
>>> Note the initial volume of the compartment is not specified in the xml.
>>>
>>> yours Andrew
>>>
>>>> -----Original Message-----
>>>> From: sbm...@li...
>>>> [mailto:sbm...@li...] On
>>>> Behalf Of Rainer Machne
>>>> Sent: 13 June 2006 11:42
>>>> To: SOSlib Development
>>>> Subject: [SOSlib-devel] variable compartment bug[Scanned]
>>>>
>>>> Folks
>>>>
>>>> Lukas has identified another serious bug!
>>>>
>>>> SOSlib doesn't support variable compartments.
>>>>
>>>> We initialize sundials with ODEs for concentrations d[A]/dt,
>>>> and sundials calculates [A] + (d[A]/dt)*h, where h is a small
>>>> time step and [A] is the initial condition or the current value.
>>>>
>>>> If we have a variable, e.g time-dependent compartment, then
>>>> d[A]/dt will change with changing compartment because the
>>>> compartment size is part of the right hand side.
>>>>
>>>> However, not only d[A]/dt is dependent on the volume, but
>>>> also [A], i.e.
>>>> the current value in data->value!
>>>>
>>>> The attached example file exemplifies this.
>>>>
>>>> So we actually should use an ODE system in amount/time
>>>> instead of concentration/time, and have a second data->value
>>>> array for concentrations to be used in formula evaluation.
>>>>
>>>> Didn't we discuss this once? I remember that I had started to
>>>> do this (ODEs in amount/time), but then it got more
>>>> complicated then I thought and something else came up.
>>>>
>>>> Can you think of any problems we will run into? Andrew, how
>>>> about the compiling version?
>>>>
>>>> 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] AIX built + dynamic compilation using gcc + help required

[Christoph F. <xt...@tb...>]

hi andrew,

 > I have managed get SOSlib to build on AIX and
 > more importantly I have managed to implement dynamic compilation using
 > g++ and shared libraries the same way as I did for windows using tcc.
 > The performance seems to be in the same ball park as the compiled code
 > was achieving on windows.  I assumed that tcc is i386 specific.

that's great news!

 > I'm effectively working on my own branch as I have not resolved the
 > `bug` in the most recent checked in source that's caused our model to
 > fail.  So I'll probably just email you the relevant source files.  I'll
 > try to document all the hacks required to get SOSlib to build
 > on AIX.

yes, please do so

 > One issue:
 > 
 > I need to get hold of the include directory for sundials and SOSlib for
 > the dynamic compilation, that is in the code and not in a build file.
 > All the files use temporary filenames
 > 
 > Is there a way to have something like:
 > 
 > #define SUNDIALS_INSTALLATION "/usr/local/"
 > #define SOSLIB_INSTALLATION "/usr/home/finney"
 > 
 > or
 > 
 > #define SUNDIALS_INCLUDE "/usr/local/include"
 > #define SOSLIB_INCLUDE "/usr/home/finney/include"
 > 
 > inserted into config.h
 > 
 > ?
 > 
 > I assume this means some kind of configure.in hack
 > I'm not exactly a guru on that so guidance would be nice.

yes that's correct. the easiest way would be to hand the required
information via command line options to the configure script into the
building process so that it automatically ends up in the config.h. are
the includes above all you need? i can write you a small m4 macro file
tonight that handles the commandline solution if you like.

 > 
 > Background:
 > 
 > At the moment I have to hard code the include path which is not ideal.
 > I tried using the same technique as windows: locate the sos
 > shared/dynamic library and then locate the include directory relative to
 > that.  I ran into a showstopper on that on AIX : missing struct
 > definition in the include files.  Anyway that's not the ideal approach
 > using the above would be better in an open-source build to install
 > environment.

i totally agree!

=;) xtof

Re: [SOSlib-devel] AIX built + dynamic compilation using gcc + help required

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

Andrew

great news!


> Is there a way to have something like:
>
> #define SUNDIALS_INSTALLATION "/usr/local/"
> #define SOSLIB_INSTALLATION "/usr/home/finney"

i guess, all we need to do is add some lines like

   AC_DEFINE([USE_SUNDIALS_SUNDIALS], 1,
             [Define to 1 to use the SUNDIALS Library])

to the config/sundials.m4 file using the existing variables
$SUNDIALS_CFLAGS, $SUNDIALS_LDFLAGS and $SUNDIALS_LIBS that we discussed 
earlier. Their value is printed as the final output of the configure 
process. They already contain the -L and -I switches.

The $prefix variable should contain the SOSlib installation path.

Maybe these variables could be used directly and you only need to add the 
following lines to config/sundials.m4

   AC_DEFINE([SUNDIALS_CFLAGS], $SUNDIALS_CFLAGS,
             [SUNDIALS include directory])
   AC_DEFINE([SUNDIALS_LDFLAGS], $SUNDIALS_LDFLAGS,
             [SUNDIALS lib directory])
   AC_DEFINE([SUNDIALS_LIBS], $SUNDIALS_LIBS,
             [SUNDIALS lib switches])

If we don't want the -L, -I, or the specific include and lib 
subdirectories we could use sed to remove these and define new variables.

For SOSlib directories, the line

   AC_DEFINE([SOSLIB_INSTALLATION], $prefix,
             [SSOSlib install directory])

should be in the configure.in file.

I think that should do it, but i am also not an expert on this.

Xtof, what do you think?

Rainer











On Wed, 14 Jun 2006, Andrew Finney wrote:

> Rainer
>
> I have managed get SOSlib to build on AIX and
> more importantly I have managed to implement dynamic compilation using
> g++ and shared libraries the same way as I did for windows using tcc.
> The performance seems to be in the same ball park as the compiled code
> was achieving on windows.  I assumed that tcc is i386 specific.
>
> I'm effectively working on my own branch as I have not resolved the
> `bug` in the most recent checked in source that's caused our model to
> fail.  So I'll probably just email you the relevant source files.  I'll
> try to document all the hacks required to get SOSlib to build
> on AIX.
>
> One issue:
>
> I need to get hold of the include directory for sundials and SOSlib for
> the dynamic compilation, that is in the code and not in a build file.
> All the files use temporary filenames
>
> Is there a way to have something like:
>
> #define SUNDIALS_INSTALLATION "/usr/local/"
> #define SOSLIB_INSTALLATION "/usr/home/finney"
>
> or
>
> #define SUNDIALS_INCLUDE "/usr/local/include"
> #define SOSLIB_INCLUDE "/usr/home/finney/include"
>
> inserted into config.h
>
> ?
>
> I assume this means some kind of configure.in hack
> I'm not exactly a guru on that so guidance would be nice.
>
> Background:
>
> At the moment I have to hard code the include path which is not ideal.
> I tried using the same technique as windows: locate the sos
> shared/dynamic library and then locate the include directory relative to
> that.  I ran into a showstopper on that on AIX : missing struct
> definition in the include files.  Anyway that's not the ideal approach
> using the above would be better in an open-source build to install
> environment.
>
> yours Andrew
>
>
>
>
>
>
>
> _______________________________________________
> sbmlsolver-devel mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>

[SOSlib-devel] AIX built + dynamic compilation using gcc + help required

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

Rainer

I have managed get SOSlib to build on AIX and
more importantly I have managed to implement dynamic compilation using
g++ and shared libraries the same way as I did for windows using tcc.
The performance seems to be in the same ball park as the compiled code
was achieving on windows.  I assumed that tcc is i386 specific.

I'm effectively working on my own branch as I have not resolved the
`bug` in the most recent checked in source that's caused our model to
fail.  So I'll probably just email you the relevant source files.  I'll
try to document all the hacks required to get SOSlib to build
on AIX.

One issue:

I need to get hold of the include directory for sundials and SOSlib for
the dynamic compilation, that is in the code and not in a build file.
All the files use temporary filenames

Is there a way to have something like:

#define SUNDIALS_INSTALLATION "/usr/local/"
#define SOSLIB_INSTALLATION "/usr/home/finney"

or

#define SUNDIALS_INCLUDE "/usr/local/include"
#define SOSLIB_INCLUDE "/usr/home/finney/include"

inserted into config.h

?

I assume this means some kind of configure.in hack
I'm not exactly a guru on that so guidance would be nice.

Background:

At the moment I have to hard code the include path which is not ideal.
I tried using the same technique as windows: locate the sos
shared/dynamic library and then locate the include directory relative to
that.  I ran into a showstopper on that on AIX : missing struct
definition in the include files.  Anyway that's not the ideal approach
using the above would be better in an open-source build to install
environment.

yours Andrew

[SOSlib-devel] variable compartment bug : correction

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

andrew, lukas, rainer!

sorry guys, the problem of compartments is so difficult :)
that i made an error, too.

given the law for concentrations dx/dt = k*y*z for a fixed volume V,
the "law" for substances X=x*V is correct even for a time-dependent volume:
dX/dt = (k*V)*y*z = (k/V)*Y*Z
whereas the law for concentrations has to be corrected:
dx/dt = k*y*z - x (dV/dt) / V

if we write down odes for substances instead of concs, we can calculate V 
either by an ode or by an assignment rule.
if we used odes for concs this would be more complicated.

so with the sbml definition of a kinetic law for a fixed volume V0
dX/dt_V0 = V0*dx/dt = V0*k*x*y = fX(concs)
the odes for substances can be written as:
dX/dt = fX() / V0 * V
that's all!
of course, via fX the concs enter the odes for substances.

so. i hope that was the last error.
anyway, let's discuss it on friday!

cheers,
stefan.


Am Dienstag 13 Juni 2006 19:01 schrieb Stefan Mueller:
> andrew, lukas, rainer!
>
> the problem of compartments (multiple or even variable) is not that easy.
>
> the definition of kinetic laws in sbml is conceptionally bad.
> ok. the sbml people wanted to ease the treatment of multiple compartments.
> and it's working...
> but among other things, it complicates the treatment of variable
> compartments. anyway, we can "work around" the current definition. (see
> below.)
>
> first, how should it be:
> in chemistry, rate laws are defined for concs,
> e.g. dx/dt=k*x*y.
> and there is a reason for this: the law is independent of the volume V!
> if you formulate "laws" for substances X=x*V,
> you get dX/dt=(k*V)*x*y=(k/V)*X*Y.
> this is not a law of chemistry, but depends also on the volume V.
> moreover, for time-dependent V the above "law" is wrong!
>
> having this in mind (?), sbml people specified dX/dt for a given volume V0,
> let's call it dX/dt_V0=(k*V0)*x*y.
> by simple calculus, we can derive dX/dt from X=x*V:
> ----------------------------------------------------
> dX/dt = dX/dt_V0 / V0 * V + X * dV/dt / V
> ----------------------------------------------------
> dV/dt can be given explicitly or derived (!) from an assignment rule.
> as rainer already suspected, we have to use odes for substances to allow
> for variable compartments. (although the kinetic laws still depend on
> concs).
>
> i hope i clarified the situation a little bit.
>
> cheers,
> stefan.
>
> Am Dienstag 13 Juni 2006 15:25 schrieb Andrew Finney:
> > Rainer
> >
> > Slow down!!
> >
> > I don't actually understand the argument:
> > why can't you have the ODEs as ODEs of concentrations:
> >
> > if S1 is in a compartment with volume C then
> >
> > d[S1]/dt = (f1() + f2() + ... fn()) / C
> >
> > f1..fn are the reaction rates which are
> > expressions that have units substance/time
> >
> > f1...fn are functions of the concentrations of the
> > species [S1]..[Sn]
> >
> > I thought that's what we'd implemented.
> >
> > Why do you need two sets of values?
> >
> > I would strongly urge we go for the approach is having
> > one set of values and carefully converting the units as is appropriate.
> >
> > fundamentally what's the problem?
> >
> > In the SBML you sent the only fly in the ointment
> > is that the initial value for the species is
> > expressed in substance units via the initialAmount attribute rather than
> > the initialConcentration
> > attribute which is in concentration units.
> >
> > All you need to do is ensure that the initialAmount
> > values are used to calculate the initialConcentration values again by
> > dividing by the volume.  Have
> > we implemented that?
> >
> > Note the initial volume of the compartment is not specified in the xml.
> >
> > yours Andrew
> >
> > > -----Original Message-----
> > > From: sbm...@li...
> > > [mailto:sbm...@li...] On
> > > Behalf Of Rainer Machne
> > > Sent: 13 June 2006 11:42
> > > To: SOSlib Development
> > > Subject: [SOSlib-devel] variable compartment bug[Scanned]
> > >
> > > Folks
> > >
> > > Lukas has identified another serious bug!
> > >
> > > SOSlib doesn't support variable compartments.
> > >
> > > We initialize sundials with ODEs for concentrations d[A]/dt,
> > > and sundials calculates [A] + (d[A]/dt)*h, where h is a small
> > > time step and [A] is the initial condition or the current value.
> > >
> > > If we have a variable, e.g time-dependent compartment, then
> > > d[A]/dt will change with changing compartment because the
> > > compartment size is part of the right hand side.
> > >
> > > However, not only d[A]/dt is dependent on the volume, but
> > > also [A], i.e.
> > > the current value in data->value!
> > >
> > > The attached example file exemplifies this.
> > >
> > > So we actually should use an ODE system in amount/time
> > > instead of concentration/time, and have a second data->value
> > > array for concentrations to be used in formula evaluation.
> > >
> > > Didn't we discuss this once? I remember that I had started to
> > > do this (ODEs in amount/time), but then it got more
> > > complicated then I thought and something else came up.
> > >
> > > Can you think of any problems we will run into? Andrew, how
> > > about the compiling version?
> > >
> > > Rainer
> >
> > _______________________________________________
> > sbmlsolver-devel mailing list
> > sbm...@li...
> > https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel

Re: [SOSlib-devel] variable compartment bug

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

andrew, lukas, rainer!

the problem of compartments (multiple or even variable) is not that easy.

the definition of kinetic laws in sbml is conceptionally bad.
ok. the sbml people wanted to ease the treatment of multiple compartments.
and it's working...
but among other things, it complicates the treatment of variable compartments.
anyway, we can "work around" the current definition. (see below.)

first, how should it be:
in chemistry, rate laws are defined for concs,
e.g. dx/dt=k*x*y.
and there is a reason for this: the law is independent of the volume V!
if you formulate "laws" for substances X=x*V,
you get dX/dt=(k*V)*x*y=(k/V)*X*Y.
this is not a law of chemistry, but depends also on the volume V.
moreover, for time-dependent V the above "law" is wrong!

having this in mind (?), sbml people specified dX/dt for a given volume V0, 
let's call it dX/dt_V0=(k*V0)*x*y.
by simple calculus, we can derive dX/dt from X=x*V:
----------------------------------------------------
dX/dt = dX/dt_V0 / V0 * V + X * dV/dt / V
----------------------------------------------------
dV/dt can be given explicitly or derived (!) from an assignment rule.
as rainer already suspected, we have to use odes for substances to allow for 
variable compartments. (although the kinetic laws still depend on concs).

i hope i clarified the situation a little bit.

cheers,
stefan.


Am Dienstag 13 Juni 2006 15:25 schrieb Andrew Finney:
> Rainer
>
> Slow down!!
>
> I don't actually understand the argument:
> why can't you have the ODEs as ODEs of concentrations:
>
> if S1 is in a compartment with volume C then
>
> d[S1]/dt = (f1() + f2() + ... fn()) / C
>
> f1..fn are the reaction rates which are
> expressions that have units substance/time
>
> f1...fn are functions of the concentrations of the
> species [S1]..[Sn]
>
> I thought that's what we'd implemented.
>
> Why do you need two sets of values?
>
> I would strongly urge we go for the approach is having
> one set of values and carefully converting the units as is appropriate.
>
> fundamentally what's the problem?
>
> In the SBML you sent the only fly in the ointment
> is that the initial value for the species is
> expressed in substance units via the initialAmount attribute rather than
> the initialConcentration
> attribute which is in concentration units.
>
> All you need to do is ensure that the initialAmount
> values are used to calculate the initialConcentration values again by
> dividing by the volume.  Have
> we implemented that?
>
> Note the initial volume of the compartment is not specified in the xml.
>
> yours Andrew
>
> > -----Original Message-----
> > From: sbm...@li...
> > [mailto:sbm...@li...] On
> > Behalf Of Rainer Machne
> > Sent: 13 June 2006 11:42
> > To: SOSlib Development
> > Subject: [SOSlib-devel] variable compartment bug[Scanned]
> >
> > Folks
> >
> > Lukas has identified another serious bug!
> >
> > SOSlib doesn't support variable compartments.
> >
> > We initialize sundials with ODEs for concentrations d[A]/dt,
> > and sundials calculates [A] + (d[A]/dt)*h, where h is a small
> > time step and [A] is the initial condition or the current value.
> >
> > If we have a variable, e.g time-dependent compartment, then
> > d[A]/dt will change with changing compartment because the
> > compartment size is part of the right hand side.
> >
> > However, not only d[A]/dt is dependent on the volume, but
> > also [A], i.e.
> > the current value in data->value!
> >
> > The attached example file exemplifies this.
> >
> > So we actually should use an ODE system in amount/time
> > instead of concentration/time, and have a second data->value
> > array for concentrations to be used in formula evaluation.
> >
> > Didn't we discuss this once? I remember that I had started to
> > do this (ODEs in amount/time), but then it got more
> > complicated then I thought and something else came up.
> >
> > Can you think of any problems we will run into? Andrew, how
> > about the compiling version?
> >
> > Rainer
>
> _______________________________________________
> sbmlsolver-devel mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel

Re: [SOSlib-devel] variable compartment bug[Scanned]

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

Also, i wonder whether and how other software supports variable 
compartments. should we ask on the sbml list?

r

On Tue, 13 Jun 2006, Andrew Finney wrote:

> Rainer
>
> I've talked with people here and this argument is correct but I only
> vaguely understand the maths - I managed to graduate without covering
> PDEs :-(
>
> I suggest you either:
>
> a) figure out with the others if there is away to do the PDE math so
> that we can support any combination rules and reactions.
> This would require I imagine some clever symbolic processing.
>
> or
>
> b) convert CVODE to substance units but then block the combination of
> rate rules for species in concentration units with rate rules for
> compartment volumes
>
> in fact there may still be problems with (b)...
>
> yours Andrew
>
>> -----Original Message-----
>> From: Rainer Machne [mailto:ra...@tb...]
>> Sent: 13 June 2006 15:46
>> To: Andrew Finney
>> Subject: RE: [SOSlib-devel] variable compartment bug[Scanned]
>>
>> Andrew
>>
>>> [S(0)] = S(0)/C(0)
>>>
>>> not
>>>
>>> [S(0)] = S(0)/C(t)
>>
>> Let's say S doesn't change over time for some reason. It
>> might even have an ODE, e.g.
>>
>> dS/dt = ( k * S(t) * activeEnzyme(t) ) / C(t)
>>
>> but during integration activeEnzyme never appears, i.e. its
>> concentrations stays 0. Thus dS/dt is always 0.
>>
>> Then in SOSlib the initialConcentration would not change and
>>
>>   [S(t)] = [S(0)] = S(0) / C(0)
>>
>> while it actually should be
>>
>>   [S(t)] = S(0) / C(t)
>>
>> This is not represented in SOSlib. Stefand and Luki pointed
>> out that the problem might be even more fundamental and that
>> we cannot represent variable compartments at all.
>>
>> if S is a function of time and of volume C, S(t,C(t)), then
>>
>> dS/dt = dS/dt + dS/dC * dC/dt
>>
>> where the d on the right hand side represent the partial
>> differential (as in PDEs).
>>
>> Maybe on Friday, when Stefan is here, we can formulate the
>> problem in more general terms.
>>
>> Rainer
>>
>>
>> On Tue, 13 Jun 2006, Andrew Finney wrote:
>>
>>> Rainer
>>>
>>> You wrote:
>>>
>>>> What cvode does is to add the concentration increase ds to the
>>>> initial
>>>> concentration:
>>>>
>>>> s(t) = s(0) + ds
>>>>
>>>> if the volume is doubled during that time e.g. by a rate rule, ds
>>>> should correctly include the changing volume because its
>> part of the
>>>> ODE.
>>>>
>>>> However, s(0)=1 has never been corrected for the changing volume!
>>>>
>>>> If the ODE ds/dt was 0 during this time, e.g. because of a missing
>>>> activator of the reaction, s(t) would still change to 0.5, because
>>>> the volume has doubled.
>>>>
>>>> This is not reflected in SOSlib!
>>>
>>> Either I'm missing something big here or...
>>>
>>> An initial concentration is an >initial< concentration
>>>
>>> at any time concentration
>>>
>>> [S] = S/C
>>>
>>> [S(t)] = S(t)/C(t)
>>>
>>> therefore
>>>
>>> [S(0)] = S(0)/C(0)
>>>
>>> not
>>>
>>> [S(0)] = S(0)/C(t)
>>>
>>> How can S(0) ever vary as the volume varies over time?
>>> S(0) is a value at only one point in time.
>>>
>>> yours Andrew
>>>
>>>> -----Original Message-----
>>>> From: Rainer Machne [mailto:ra...@tb...]
>>>> Sent: 13 June 2006 15:09
>>>> To: Andrew Finney
>>>> Cc: SOSlib Development
>>>> Subject: RE: [SOSlib-devel] variable compartment bug[Scanned]
>>>>
>>>> Andrew
>>>>
>>>>
>>>> I have added a corrected and more clear version of the
>> example file.
>>>>
>>>>
>>>>> All you need to do is ensure that the initialAmount values
>>>> are used to
>>>>> calculate the initialConcentration values again by
>> dividing by the
>>>>> volume.  Have we implemented that?
>>>>
>>>> Yes, the internal SBML ode model only contains
>> initialConcentrations;
>>>> initialAmounts from the input model have all been converted by
>>>> dividing by compartment size.
>>>>
>>>>
>>>>> if S1 is in a compartment with volume C then
>>>>>
>>>>> d[S1]/dt = (f1() + f2() + ... fn()) / C
>>>>>
>>>>> f1..fn are the reaction rates which are expressions that
>> have units
>>>>> substance/time
>>>>>
>>>>> f1...fn are functions of the concentrations of the species
>>>>> [S1]..[Sn]
>>>>>
>>>>> I thought that's what we'd implemented.
>>>>
>>>> Yes, that is what we have.
>>>>
>>>>
>>>>> Why do you need two sets of values?
>>>>
>>>> Ok, I'll try to explain in more detail.
>>>>
>>>> I change the notation to
>>>> S ... amount of molecule S
>>>> s ... concentration, [S] = S/v
>>>> v ... volume
>>>>
>>>>
>>>> Imagine we start with initialConcentration s(0) = 1, and integrate
>>>> from 0 to time 1.
>>>>
>>>> What cvode does is to add the concentration increase ds to the
>>>> initial
>>>> concentration:
>>>>
>>>> s(t) = s(0) + ds
>>>>
>>>> if the volume is doubled during that time e.g. by a rate rule, ds
>>>> should correctly include the changing volume because its
>> part of the
>>>> ODE.
>>>>
>>>> However, s(0)=1 has never been corrected for the changing volume!
>>>>
>>>> If the ODE ds/dt was 0 during this time, e.g. because of a missing
>>>> activator of the reaction, s(t) would still change to 0.5, because
>>>> the volume has doubled.
>>>>
>>>> This is not reflected in SOSlib!
>>>>
>>>> To the example XML:
>>>>
>>>>> Note the initial volume of the compartment is not specified
>>>> in the xml.
>>>>
>>>> Sorry, I tried the model with old version which still had the
>>>> `missing parameter bug' from last week.
>>>> See the attached corrected file.
>>>>
>>>> The compartment volume increases to 11 because of its rate rule
>>>> d(volume)/dt = + 0.1
>>>>
>>>> Substance s1 starts with concentration 1 and is totally
>> consumed by
>>>> the irreversible reaction
>>>>
>>>> S1 -> S2; kineticLaw = k+S1
>>>>
>>>> which moves all molecules to S2.
>>>>
>>>> Substance S2 would have a final concentration of 1, if the
>>>> compartment still had volume 1, but not for a final volume of 11.
>>>>
>>>> The final concentration should be 1/11.
>>>>
>>>> The totalConcentration in the example file should also decrease to
>>>> 1/11.
>>>>
>>>>
>>>> SOSlib and the ODE division by volume only corrects the change of
>>>> concentration but not the initial concentration, or
>> generally spoken,
>>>> the concentration of the last time step, which also has decreased.
>>>>
>>>> The only solution i can think of, is to define ODEs in
>> substance/time
>>>> and do the division independently of the ODE system.
>>>>
>>>> Rainer
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, 13 Jun 2006, Andrew Finney wrote:
>>>>
>>>>> Rainer
>>>>>
>>>>> Slow down!!
>>>>>
>>>>> I don't actually understand the argument:
>>>>> why can't you have the ODEs as ODEs of concentrations:
>>>>>
>>>>> if S1 is in a compartment with volume C then
>>>>>
>>>>> d[S1]/dt = (f1() + f2() + ... fn()) / C
>>>>>
>>>>> f1..fn are the reaction rates which are expressions that
>> have units
>>>>> substance/time
>>>>>
>>>>> f1...fn are functions of the concentrations of the species
>>>>> [S1]..[Sn]
>>>>>
>>>>> I thought that's what we'd implemented.
>>>>>
>>>>> Why do you need two sets of values?
>>>>>
>>>>> I would strongly urge we go for the approach is having one set of
>>>>> values and carefully converting the units as is
>>>> appropriate.
>>>>>
>>>>> fundamentally what's the problem?
>>>>>
>>>>> In the SBML you sent the only fly in the ointment is that the
>>>>> initial value for the species is expressed in substance units via
>>>>> the initialAmount
>>>> attribute rather than
>>>>> the initialConcentration
>>>>> attribute which is in concentration units.
>>>>>
>>>>> All you need to do is ensure that the initialAmount
>> values are used
>>>>> to calculate the initialConcentration
>>>> values again by
>>>>> dividing by the volume.  Have
>>>>> we implemented that?
>>>>>
>>>>> Note the initial volume of the compartment is not specified
>>>> in the xml.
>>>>>
>>>>> yours Andrew
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: sbm...@li...
>>>>>> [mailto:sbm...@li...]
>> On Behalf
>>>>>> Of Rainer Machne
>>>>>> Sent: 13 June 2006 11:42
>>>>>> To: SOSlib Development
>>>>>> Subject: [SOSlib-devel] variable compartment bug[Scanned]
>>>>>>
>>>>>> Folks
>>>>>>
>>>>>> Lukas has identified another serious bug!
>>>>>>
>>>>>> SOSlib doesn't support variable compartments.
>>>>>>
>>>>>> We initialize sundials with ODEs for concentrations d[A]/dt, and
>>>>>> sundials calculates [A] + (d[A]/dt)*h, where h is a
>> small time step
>>>>>> and [A] is the initial condition or the current value.
>>>>>>
>>>>>> If we have a variable, e.g time-dependent compartment,
>> then d[A]/dt
>>>>>> will change with changing compartment because the
>> compartment size
>>>>>> is part of the right hand side.
>>>>>>
>>>>>> However, not only d[A]/dt is dependent on the volume,
>> but also [A],
>>>>>> i.e.
>>>>>> the current value in data->value!
>>>>>>
>>>>>> The attached example file exemplifies this.
>>>>>>
>>>>>> So we actually should use an ODE system in amount/time
>> instead of
>>>>>> concentration/time, and have a second data->value array for
>>>>>> concentrations to be used in formula evaluation.
>>>>>>
>>>>>> Didn't we discuss this once? I remember that I had started to do
>>>>>> this (ODEs in amount/time), but then it got more
>> complicated then I
>>>>>> thought and something else came up.
>>>>>>
>>>>>> Can you think of any problems we will run into? Andrew,
>> how about
>>>>>> the compiling version?
>>>>>>
>>>>>> Rainer
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: [SOSlib-devel] variable compartment bug[Scanned]

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

Andrew

>
> a) figure out with the others if there is away to do the PDE math so
> that we can support any combination rules and reactions.
> This would require I imagine some clever symbolic processing.
>
> or
>
> b) convert CVODE to substance units but then block the combination of
> rate rules for species in concentration units with rate rules for
> compartment volumes
>
> in fact there may still be problems with (b)...

we need variable compartments here for an upcoming application using 
SOSlib!

i guess b is more likely to happen. i actually once had some code where i 
started to do this. can't remember why i did start and why i didn't 
finish. my understanding of math and programming is rather intuitive and 
maybe i had an unconscious idea about all these problems :)

Rainer


On Tue, 13 Jun 2006, Andrew Finney wrote:

> Rainer
>
> I've talked with people here and this argument is correct but I only
> vaguely understand the maths - I managed to graduate without covering
> PDEs :-(
>
> I suggest you either:
>
> a) figure out with the others if there is away to do the PDE math so
> that we can support any combination rules and reactions.
> This would require I imagine some clever symbolic processing.
>
> or
>
> b) convert CVODE to substance units but then block the combination of
> rate rules for species in concentration units with rate rules for
> compartment volumes
>
> in fact there may still be problems with (b)...
>
> yours Andrew
>
>> -----Original Message-----
>> From: Rainer Machne [mailto:ra...@tb...]
>> Sent: 13 June 2006 15:46
>> To: Andrew Finney
>> Subject: RE: [SOSlib-devel] variable compartment bug[Scanned]
>>
>> Andrew
>>
>>> [S(0)] = S(0)/C(0)
>>>
>>> not
>>>
>>> [S(0)] = S(0)/C(t)
>>
>> Let's say S doesn't change over time for some reason. It
>> might even have an ODE, e.g.
>>
>> dS/dt = ( k * S(t) * activeEnzyme(t) ) / C(t)
>>
>> but during integration activeEnzyme never appears, i.e. its
>> concentrations stays 0. Thus dS/dt is always 0.
>>
>> Then in SOSlib the initialConcentration would not change and
>>
>>   [S(t)] = [S(0)] = S(0) / C(0)
>>
>> while it actually should be
>>
>>   [S(t)] = S(0) / C(t)
>>
>> This is not represented in SOSlib. Stefand and Luki pointed
>> out that the problem might be even more fundamental and that
>> we cannot represent variable compartments at all.
>>
>> if S is a function of time and of volume C, S(t,C(t)), then
>>
>> dS/dt = dS/dt + dS/dC * dC/dt
>>
>> where the d on the right hand side represent the partial
>> differential (as in PDEs).
>>
>> Maybe on Friday, when Stefan is here, we can formulate the
>> problem in more general terms.
>>
>> Rainer
>>
>>
>> On Tue, 13 Jun 2006, Andrew Finney wrote:
>>
>>> Rainer
>>>
>>> You wrote:
>>>
>>>> What cvode does is to add the concentration increase ds to the
>>>> initial
>>>> concentration:
>>>>
>>>> s(t) = s(0) + ds
>>>>
>>>> if the volume is doubled during that time e.g. by a rate rule, ds
>>>> should correctly include the changing volume because its
>> part of the
>>>> ODE.
>>>>
>>>> However, s(0)=1 has never been corrected for the changing volume!
>>>>
>>>> If the ODE ds/dt was 0 during this time, e.g. because of a missing
>>>> activator of the reaction, s(t) would still change to 0.5, because
>>>> the volume has doubled.
>>>>
>>>> This is not reflected in SOSlib!
>>>
>>> Either I'm missing something big here or...
>>>
>>> An initial concentration is an >initial< concentration
>>>
>>> at any time concentration
>>>
>>> [S] = S/C
>>>
>>> [S(t)] = S(t)/C(t)
>>>
>>> therefore
>>>
>>> [S(0)] = S(0)/C(0)
>>>
>>> not
>>>
>>> [S(0)] = S(0)/C(t)
>>>
>>> How can S(0) ever vary as the volume varies over time?
>>> S(0) is a value at only one point in time.
>>>
>>> yours Andrew
>>>
>>>> -----Original Message-----
>>>> From: Rainer Machne [mailto:ra...@tb...]
>>>> Sent: 13 June 2006 15:09
>>>> To: Andrew Finney
>>>> Cc: SOSlib Development
>>>> Subject: RE: [SOSlib-devel] variable compartment bug[Scanned]
>>>>
>>>> Andrew
>>>>
>>>>
>>>> I have added a corrected and more clear version of the
>> example file.
>>>>
>>>>
>>>>> All you need to do is ensure that the initialAmount values
>>>> are used to
>>>>> calculate the initialConcentration values again by
>> dividing by the
>>>>> volume.  Have we implemented that?
>>>>
>>>> Yes, the internal SBML ode model only contains
>> initialConcentrations;
>>>> initialAmounts from the input model have all been converted by
>>>> dividing by compartment size.
>>>>
>>>>
>>>>> if S1 is in a compartment with volume C then
>>>>>
>>>>> d[S1]/dt = (f1() + f2() + ... fn()) / C
>>>>>
>>>>> f1..fn are the reaction rates which are expressions that
>> have units
>>>>> substance/time
>>>>>
>>>>> f1...fn are functions of the concentrations of the species
>>>>> [S1]..[Sn]
>>>>>
>>>>> I thought that's what we'd implemented.
>>>>
>>>> Yes, that is what we have.
>>>>
>>>>
>>>>> Why do you need two sets of values?
>>>>
>>>> Ok, I'll try to explain in more detail.
>>>>
>>>> I change the notation to
>>>> S ... amount of molecule S
>>>> s ... concentration, [S] = S/v
>>>> v ... volume
>>>>
>>>>
>>>> Imagine we start with initialConcentration s(0) = 1, and integrate
>>>> from 0 to time 1.
>>>>
>>>> What cvode does is to add the concentration increase ds to the
>>>> initial
>>>> concentration:
>>>>
>>>> s(t) = s(0) + ds
>>>>
>>>> if the volume is doubled during that time e.g. by a rate rule, ds
>>>> should correctly include the changing volume because its
>> part of the
>>>> ODE.
>>>>
>>>> However, s(0)=1 has never been corrected for the changing volume!
>>>>
>>>> If the ODE ds/dt was 0 during this time, e.g. because of a missing
>>>> activator of the reaction, s(t) would still change to 0.5, because
>>>> the volume has doubled.
>>>>
>>>> This is not reflected in SOSlib!
>>>>
>>>> To the example XML:
>>>>
>>>>> Note the initial volume of the compartment is not specified
>>>> in the xml.
>>>>
>>>> Sorry, I tried the model with old version which still had the
>>>> `missing parameter bug' from last week.
>>>> See the attached corrected file.
>>>>
>>>> The compartment volume increases to 11 because of its rate rule
>>>> d(volume)/dt = + 0.1
>>>>
>>>> Substance s1 starts with concentration 1 and is totally
>> consumed by
>>>> the irreversible reaction
>>>>
>>>> S1 -> S2; kineticLaw = k+S1
>>>>
>>>> which moves all molecules to S2.
>>>>
>>>> Substance S2 would have a final concentration of 1, if the
>>>> compartment still had volume 1, but not for a final volume of 11.
>>>>
>>>> The final concentration should be 1/11.
>>>>
>>>> The totalConcentration in the example file should also decrease to
>>>> 1/11.
>>>>
>>>>
>>>> SOSlib and the ODE division by volume only corrects the change of
>>>> concentration but not the initial concentration, or
>> generally spoken,
>>>> the concentration of the last time step, which also has decreased.
>>>>
>>>> The only solution i can think of, is to define ODEs in
>> substance/time
>>>> and do the division independently of the ODE system.
>>>>
>>>> Rainer
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, 13 Jun 2006, Andrew Finney wrote:
>>>>
>>>>> Rainer
>>>>>
>>>>> Slow down!!
>>>>>
>>>>> I don't actually understand the argument:
>>>>> why can't you have the ODEs as ODEs of concentrations:
>>>>>
>>>>> if S1 is in a compartment with volume C then
>>>>>
>>>>> d[S1]/dt = (f1() + f2() + ... fn()) / C
>>>>>
>>>>> f1..fn are the reaction rates which are expressions that
>> have units
>>>>> substance/time
>>>>>
>>>>> f1...fn are functions of the concentrations of the species
>>>>> [S1]..[Sn]
>>>>>
>>>>> I thought that's what we'd implemented.
>>>>>
>>>>> Why do you need two sets of values?
>>>>>
>>>>> I would strongly urge we go for the approach is having one set of
>>>>> values and carefully converting the units as is
>>>> appropriate.
>>>>>
>>>>> fundamentally what's the problem?
>>>>>
>>>>> In the SBML you sent the only fly in the ointment is that the
>>>>> initial value for the species is expressed in substance units via
>>>>> the initialAmount
>>>> attribute rather than
>>>>> the initialConcentration
>>>>> attribute which is in concentration units.
>>>>>
>>>>> All you need to do is ensure that the initialAmount
>> values are used
>>>>> to calculate the initialConcentration
>>>> values again by
>>>>> dividing by the volume.  Have
>>>>> we implemented that?
>>>>>
>>>>> Note the initial volume of the compartment is not specified
>>>> in the xml.
>>>>>
>>>>> yours Andrew
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: sbm...@li...
>>>>>> [mailto:sbm...@li...]
>> On Behalf
>>>>>> Of Rainer Machne
>>>>>> Sent: 13 June 2006 11:42
>>>>>> To: SOSlib Development
>>>>>> Subject: [SOSlib-devel] variable compartment bug[Scanned]
>>>>>>
>>>>>> Folks
>>>>>>
>>>>>> Lukas has identified another serious bug!
>>>>>>
>>>>>> SOSlib doesn't support variable compartments.
>>>>>>
>>>>>> We initialize sundials with ODEs for concentrations d[A]/dt, and
>>>>>> sundials calculates [A] + (d[A]/dt)*h, where h is a
>> small time step
>>>>>> and [A] is the initial condition or the current value.
>>>>>>
>>>>>> If we have a variable, e.g time-dependent compartment,
>> then d[A]/dt
>>>>>> will change with changing compartment because the
>> compartment size
>>>>>> is part of the right hand side.
>>>>>>
>>>>>> However, not only d[A]/dt is dependent on the volume,
>> but also [A],
>>>>>> i.e.
>>>>>> the current value in data->value!
>>>>>>
>>>>>> The attached example file exemplifies this.
>>>>>>
>>>>>> So we actually should use an ODE system in amount/time
>> instead of
>>>>>> concentration/time, and have a second data->value array for
>>>>>> concentrations to be used in formula evaluation.
>>>>>>
>>>>>> Didn't we discuss this once? I remember that I had started to do
>>>>>> this (ODEs in amount/time), but then it got more
>> complicated then I
>>>>>> thought and something else came up.
>>>>>>
>>>>>> Can you think of any problems we will run into? Andrew,
>> how about
>>>>>> the compiling version?
>>>>>>
>>>>>> Rainer
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: [SOSlib-devel] variable compartment bug[Scanned]

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

Rainer

I've talked with people here and this argument is correct but I only
vaguely understand the maths - I managed to graduate without covering
PDEs :-(=20

I suggest you either:

a) figure out with the others if there is away to do the PDE math so
that we can support any combination rules and reactions.
This would require I imagine some clever symbolic processing.

or

b) convert CVODE to substance units but then block the combination of
rate rules for species in concentration units with rate rules for
compartment volumes

in fact there may still be problems with (b)...

yours Andrew

> -----Original Message-----
> From: Rainer Machne [mailto:ra...@tb...]=20
> Sent: 13 June 2006 15:46
> To: Andrew Finney
> Subject: RE: [SOSlib-devel] variable compartment bug[Scanned]
>=20
> Andrew
>=20
> > [S(0)] =3D S(0)/C(0)
> >
> > not
> >
> > [S(0)] =3D S(0)/C(t)
>=20
> Let's say S doesn't change over time for some reason. It=20
> might even have an ODE, e.g.
>=20
> dS/dt =3D ( k * S(t) * activeEnzyme(t) ) / C(t)
>=20
> but during integration activeEnzyme never appears, i.e. its=20
> concentrations stays 0. Thus dS/dt is always 0.
>=20
> Then in SOSlib the initialConcentration would not change and
>=20
>   [S(t)] =3D [S(0)] =3D S(0) / C(0)
>=20
> while it actually should be
>=20
>   [S(t)] =3D S(0) / C(t)
>=20
> This is not represented in SOSlib. Stefand and Luki pointed=20
> out that the problem might be even more fundamental and that=20
> we cannot represent variable compartments at all.
>=20
> if S is a function of time and of volume C, S(t,C(t)), then
>=20
> dS/dt =3D dS/dt + dS/dC * dC/dt
>=20
> where the d on the right hand side represent the partial=20
> differential (as in PDEs).
>=20
> Maybe on Friday, when Stefan is here, we can formulate the=20
> problem in more general terms.
>=20
> Rainer
>=20
>=20
> On Tue, 13 Jun 2006, Andrew Finney wrote:
>=20
> > Rainer
> >
> > You wrote:
> >
> >> What cvode does is to add the concentration increase ds to the=20
> >> initial
> >> concentration:
> >>
> >> s(t) =3D s(0) + ds
> >>
> >> if the volume is doubled during that time e.g. by a rate rule, ds=20
> >> should correctly include the changing volume because its=20
> part of the=20
> >> ODE.
> >>
> >> However, s(0)=3D1 has never been corrected for the changing volume!
> >>
> >> If the ODE ds/dt was 0 during this time, e.g. because of a missing=20
> >> activator of the reaction, s(t) would still change to 0.5, because=20
> >> the volume has doubled.
> >>
> >> This is not reflected in SOSlib!
> >
> > Either I'm missing something big here or...
> >
> > An initial concentration is an >initial< concentration
> >
> > at any time concentration
> >
> > [S] =3D S/C
> >
> > [S(t)] =3D S(t)/C(t)
> >
> > therefore
> >
> > [S(0)] =3D S(0)/C(0)
> >
> > not
> >
> > [S(0)] =3D S(0)/C(t)
> >
> > How can S(0) ever vary as the volume varies over time?
> > S(0) is a value at only one point in time.
> >
> > yours Andrew
> >
> >> -----Original Message-----
> >> From: Rainer Machne [mailto:ra...@tb...]
> >> Sent: 13 June 2006 15:09
> >> To: Andrew Finney
> >> Cc: SOSlib Development
> >> Subject: RE: [SOSlib-devel] variable compartment bug[Scanned]
> >>
> >> Andrew
> >>
> >>
> >> I have added a corrected and more clear version of the=20
> example file.
> >>
> >>
> >>> All you need to do is ensure that the initialAmount values
> >> are used to
> >>> calculate the initialConcentration values again by=20
> dividing by the=20
> >>> volume.  Have we implemented that?
> >>
> >> Yes, the internal SBML ode model only contains=20
> initialConcentrations;=20
> >> initialAmounts from the input model have all been converted by=20
> >> dividing by compartment size.
> >>
> >>
> >>> if S1 is in a compartment with volume C then
> >>>
> >>> d[S1]/dt =3D (f1() + f2() + ... fn()) / C
> >>>
> >>> f1..fn are the reaction rates which are expressions that=20
> have units=20
> >>> substance/time
> >>>
> >>> f1...fn are functions of the concentrations of the species=20
> >>> [S1]..[Sn]
> >>>
> >>> I thought that's what we'd implemented.
> >>
> >> Yes, that is what we have.
> >>
> >>
> >>> Why do you need two sets of values?
> >>
> >> Ok, I'll try to explain in more detail.
> >>
> >> I change the notation to
> >> S ... amount of molecule S
> >> s ... concentration, [S] =3D S/v
> >> v ... volume
> >>
> >>
> >> Imagine we start with initialConcentration s(0) =3D 1, and =
integrate=20
> >> from 0 to time 1.
> >>
> >> What cvode does is to add the concentration increase ds to the=20
> >> initial
> >> concentration:
> >>
> >> s(t) =3D s(0) + ds
> >>
> >> if the volume is doubled during that time e.g. by a rate rule, ds=20
> >> should correctly include the changing volume because its=20
> part of the=20
> >> ODE.
> >>
> >> However, s(0)=3D1 has never been corrected for the changing volume!
> >>
> >> If the ODE ds/dt was 0 during this time, e.g. because of a missing=20
> >> activator of the reaction, s(t) would still change to 0.5, because=20
> >> the volume has doubled.
> >>
> >> This is not reflected in SOSlib!
> >>
> >> To the example XML:
> >>
> >>> Note the initial volume of the compartment is not specified
> >> in the xml.
> >>
> >> Sorry, I tried the model with old version which still had the=20
> >> `missing parameter bug' from last week.
> >> See the attached corrected file.
> >>
> >> The compartment volume increases to 11 because of its rate rule=20
> >> d(volume)/dt =3D + 0.1
> >>
> >> Substance s1 starts with concentration 1 and is totally=20
> consumed by=20
> >> the irreversible reaction
> >>
> >> S1 -> S2; kineticLaw =3D k+S1
> >>
> >> which moves all molecules to S2.
> >>
> >> Substance S2 would have a final concentration of 1, if the=20
> >> compartment still had volume 1, but not for a final volume of 11.
> >>
> >> The final concentration should be 1/11.
> >>
> >> The totalConcentration in the example file should also decrease to=20
> >> 1/11.
> >>
> >>
> >> SOSlib and the ODE division by volume only corrects the change of=20
> >> concentration but not the initial concentration, or=20
> generally spoken,=20
> >> the concentration of the last time step, which also has decreased.
> >>
> >> The only solution i can think of, is to define ODEs in=20
> substance/time=20
> >> and do the division independently of the ODE system.
> >>
> >> Rainer
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Tue, 13 Jun 2006, Andrew Finney wrote:
> >>
> >>> Rainer
> >>>
> >>> Slow down!!
> >>>
> >>> I don't actually understand the argument:
> >>> why can't you have the ODEs as ODEs of concentrations:
> >>>
> >>> if S1 is in a compartment with volume C then
> >>>
> >>> d[S1]/dt =3D (f1() + f2() + ... fn()) / C
> >>>
> >>> f1..fn are the reaction rates which are expressions that=20
> have units=20
> >>> substance/time
> >>>
> >>> f1...fn are functions of the concentrations of the species=20
> >>> [S1]..[Sn]
> >>>
> >>> I thought that's what we'd implemented.
> >>>
> >>> Why do you need two sets of values?
> >>>
> >>> I would strongly urge we go for the approach is having one set of=20
> >>> values and carefully converting the units as is
> >> appropriate.
> >>>
> >>> fundamentally what's the problem?
> >>>
> >>> In the SBML you sent the only fly in the ointment is that the=20
> >>> initial value for the species is expressed in substance units via=20
> >>> the initialAmount
> >> attribute rather than
> >>> the initialConcentration
> >>> attribute which is in concentration units.
> >>>
> >>> All you need to do is ensure that the initialAmount=20
> values are used=20
> >>> to calculate the initialConcentration
> >> values again by
> >>> dividing by the volume.  Have
> >>> we implemented that?
> >>>
> >>> Note the initial volume of the compartment is not specified
> >> in the xml.
> >>>
> >>> yours Andrew
> >>>
> >>>> -----Original Message-----
> >>>> From: sbm...@li...
> >>>> [mailto:sbm...@li...]=20
> On Behalf=20
> >>>> Of Rainer Machne
> >>>> Sent: 13 June 2006 11:42
> >>>> To: SOSlib Development
> >>>> Subject: [SOSlib-devel] variable compartment bug[Scanned]
> >>>>
> >>>> Folks
> >>>>
> >>>> Lukas has identified another serious bug!
> >>>>
> >>>> SOSlib doesn't support variable compartments.
> >>>>
> >>>> We initialize sundials with ODEs for concentrations d[A]/dt, and=20
> >>>> sundials calculates [A] + (d[A]/dt)*h, where h is a=20
> small time step=20
> >>>> and [A] is the initial condition or the current value.
> >>>>
> >>>> If we have a variable, e.g time-dependent compartment,=20
> then d[A]/dt=20
> >>>> will change with changing compartment because the=20
> compartment size=20
> >>>> is part of the right hand side.
> >>>>
> >>>> However, not only d[A]/dt is dependent on the volume,=20
> but also [A],=20
> >>>> i.e.
> >>>> the current value in data->value!
> >>>>
> >>>> The attached example file exemplifies this.
> >>>>
> >>>> So we actually should use an ODE system in amount/time=20
> instead of=20
> >>>> concentration/time, and have a second data->value array for=20
> >>>> concentrations to be used in formula evaluation.
> >>>>
> >>>> Didn't we discuss this once? I remember that I had started to do=20
> >>>> this (ODEs in amount/time), but then it got more=20
> complicated then I=20
> >>>> thought and something else came up.
> >>>>
> >>>> Can you think of any problems we will run into? Andrew,=20
> how about=20
> >>>> the compiling version?
> >>>>
> >>>> Rainer
> >>>>
> >>>
> >>
> >
>=20

Re: [SOSlib-devel] variable compartment bug[Scanned] (fwd)

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

Andrew

> [S(0)] = S(0)/C(0)
> 
> not
> 
> [S(0)] = S(0)/C(t)

Let's say S doesn't change over time for some reason. It might even have an 
ODE, e.g.

dS/dt = ( k * S(t) * activeEnzyme(t) ) / C(t)

but during integration activeEnzyme never appears, i.e. its concentrations 
stays 0. Thus dS/dt is always 0.

Then in SOSlib the initialConcentration would not change and

  [S(t)] = [S(0)] = S(0) / C(0)

while it actually should be

  [S(t)] = S(0) / C(t)

This is not represented in SOSlib. Stefand and Luki pointed out that the 
problem might be even more fundamental and that we cannot represent variable 
compartments at all.

if S is a function of time and of volume C, S(t,C(t)),
then

dS/dt = dS/dt + dS/dC * dC/dt

where the d on the right hand side represent the partial differential (as in 
PDEs).

Maybe on Friday, when Stefan is here, we can formulate the problem in more 
general terms.

Rainer


On Tue, 13 Jun 2006, Andrew Finney wrote:

> Rainer
> 
> You wrote:
> 
>> What cvode does is to add the concentration increase ds to
>> the initial
>> concentration:
>> 
>> s(t) = s(0) + ds
>> 
>> if the volume is doubled during that time e.g. by a rate
>> rule, ds should
>> correctly include the changing volume because its part of the ODE.
>> 
>> However, s(0)=1 has never been corrected for the changing volume!
>> 
>> If the ODE ds/dt was 0 during this time, e.g. because of a missing
>> activator of the reaction, s(t) would still change to 0.5,
>> because the
>> volume has doubled.
>> 
>> This is not reflected in SOSlib!
> 
> Either I'm missing something big here or...
> 
> An initial concentration is an >initial< concentration
> 
> at any time concentration
> 
> [S] = S/C
> 
> [S(t)] = S(t)/C(t)
> 
> therefore
> 
> [S(0)] = S(0)/C(0)
> 
> not
> 
> [S(0)] = S(0)/C(t)
> 
> How can S(0) ever vary as the volume varies over time?
> S(0) is a value at only one point in time.
> 
> yours Andrew
> 
>> -----Original Message-----
>> From: Rainer Machne [mailto:ra...@tb...]
>> Sent: 13 June 2006 15:09
>> To: Andrew Finney
>> Cc: SOSlib Development
>> Subject: RE: [SOSlib-devel] variable compartment bug[Scanned]
>> 
>> Andrew
>> 
>> 
>> I have added a corrected and more clear version of the example file.
>> 
>> 
>>> All you need to do is ensure that the initialAmount values
>> are used to
>>> calculate the initialConcentration values again by dividing by the
>>> volume.  Have we implemented that?
>> 
>> Yes, the internal SBML ode model only contains
>> initialConcentrations; initialAmounts from the input model
>> have all been converted by dividing by compartment size.
>> 
>> 
>>> if S1 is in a compartment with volume C then
>>> 
>>> d[S1]/dt = (f1() + f2() + ... fn()) / C
>>> 
>>> f1..fn are the reaction rates which are
>>> expressions that have units substance/time
>>> 
>>> f1...fn are functions of the concentrations of the
>>> species [S1]..[Sn]
>>> 
>>> I thought that's what we'd implemented.
>> 
>> Yes, that is what we have.
>> 
>> 
>>> Why do you need two sets of values?
>> 
>> Ok, I'll try to explain in more detail.
>> 
>> I change the notation to
>> S ... amount of molecule S
>> s ... concentration, [S] = S/v
>> v ... volume
>> 
>> 
>> Imagine we start with initialConcentration s(0) = 1,
>> and integrate from 0 to time 1.
>> 
>> What cvode does is to add the concentration increase ds to
>> the initial
>> concentration:
>> 
>> s(t) = s(0) + ds
>> 
>> if the volume is doubled during that time e.g. by a rate
>> rule, ds should
>> correctly include the changing volume because its part of the ODE.
>> 
>> However, s(0)=1 has never been corrected for the changing volume!
>> 
>> If the ODE ds/dt was 0 during this time, e.g. because of a missing
>> activator of the reaction, s(t) would still change to 0.5,
>> because the
>> volume has doubled.
>> 
>> This is not reflected in SOSlib!
>> 
>> To the example XML:
>> 
>>> Note the initial volume of the compartment is not specified
>> in the xml.
>> 
>> Sorry, I tried the model with old version which still had the
>> `missing
>> parameter bug' from last week.
>> See the attached corrected file.
>> 
>> The compartment volume increases to 11 because of its rate rule
>> d(volume)/dt = + 0.1
>> 
>> Substance s1 starts with concentration 1 and is totally
>> consumed by the
>> irreversible reaction
>> 
>> S1 -> S2; kineticLaw = k+S1
>> 
>> which moves all molecules to S2.
>> 
>> Substance S2 would have a final concentration of 1, if the
>> compartment
>> still had volume 1, but not for a final volume of 11.
>> 
>> The final concentration should be 1/11.
>> 
>> The totalConcentration in the example file should also
>> decrease to 1/11.
>> 
>> 
>> SOSlib and the ODE division by volume only corrects the change of
>> concentration but not the initial concentration, or generally
>> spoken, the
>> concentration of the last time step, which also has decreased.
>> 
>> The only solution i can think of, is to define ODEs in
>> substance/time and
>> do the division independently of the ODE system.
>> 
>> Rainer
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> On Tue, 13 Jun 2006, Andrew Finney wrote:
>> 
>>> Rainer
>>> 
>>> Slow down!!
>>> 
>>> I don't actually understand the argument:
>>> why can't you have the ODEs as ODEs of concentrations:
>>> 
>>> if S1 is in a compartment with volume C then
>>> 
>>> d[S1]/dt = (f1() + f2() + ... fn()) / C
>>> 
>>> f1..fn are the reaction rates which are
>>> expressions that have units substance/time
>>> 
>>> f1...fn are functions of the concentrations of the
>>> species [S1]..[Sn]
>>> 
>>> I thought that's what we'd implemented.
>>> 
>>> Why do you need two sets of values?
>>> 
>>> I would strongly urge we go for the approach is having
>>> one set of values and carefully converting the units as is
>> appropriate.
>>> 
>>> fundamentally what's the problem?
>>> 
>>> In the SBML you sent the only fly in the ointment
>>> is that the initial value for the species is
>>> expressed in substance units via the initialAmount
>> attribute rather than
>>> the initialConcentration
>>> attribute which is in concentration units.
>>> 
>>> All you need to do is ensure that the initialAmount
>>> values are used to calculate the initialConcentration
>> values again by
>>> dividing by the volume.  Have
>>> we implemented that?
>>> 
>>> Note the initial volume of the compartment is not specified
>> in the xml.
>>> 
>>> yours Andrew
>>> 
>>>> -----Original Message-----
>>>> From: sbm...@li...
>>>> [mailto:sbm...@li...] On
>>>> Behalf Of Rainer Machne
>>>> Sent: 13 June 2006 11:42
>>>> To: SOSlib Development
>>>> Subject: [SOSlib-devel] variable compartment bug[Scanned]
>>>> 
>>>> Folks
>>>> 
>>>> Lukas has identified another serious bug!
>>>> 
>>>> SOSlib doesn't support variable compartments.
>>>> 
>>>> We initialize sundials with ODEs for concentrations d[A]/dt,
>>>> and sundials calculates [A] + (d[A]/dt)*h, where h is a small
>>>> time step and [A] is the initial condition or the current value.
>>>> 
>>>> If we have a variable, e.g time-dependent compartment, then
>>>> d[A]/dt will change with changing compartment because the
>>>> compartment size is part of the right hand side.
>>>> 
>>>> However, not only d[A]/dt is dependent on the volume, but
>>>> also [A], i.e.
>>>> the current value in data->value!
>>>> 
>>>> The attached example file exemplifies this.
>>>> 
>>>> So we actually should use an ODE system in amount/time
>>>> instead of concentration/time, and have a second data->value
>>>> array for concentrations to be used in formula evaluation.
>>>> 
>>>> Didn't we discuss this once? I remember that I had started to
>>>> do this (ODEs in amount/time), but then it got more
>>>> complicated then I thought and something else came up.
>>>> 
>>>> Can you think of any problems we will run into? Andrew, how
>>>> about the compiling version?
>>>> 
>>>> Rainer
>>>> 
>>> 
>> 
>

Re: [SOSlib-devel] variable compartment bug[Scanned]

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

Andrew

> Intuitively I can't see why this formulae is wrong
> but hey what do I know!
>
> My calculus really isn't up to figuring this out!
> sorry I'm a software engineer.  I guess I should know for SBML and all=20
that b$
>

I'm a biologist, so i really don't know much about this either :)

luckily we have lukas (chemist) and stefan (physicist) to help out.

> I don't have problem in changing SOS to using amount units for the
> species variables.  However you will still have a problem when a model
> contains a rate rule in concentration units.  What happens then?

Mhm ... we will try to figure out on Friday if we can represent variable=20
compartments at all ...

i'm quite confused now :(

Rainer






On Tue, 13 Jun 2006, Andrew Finney wrote:

> Rainer
>
> I think I understand your English argument
>
> my last email was really just a comment on
> how you expressed your argument :-)
>
> I don't exactly understand why the math doesn't work.
> CVODE solves any correctly defined ODE system
> if CVODE produces the wrong results then we've got the formulae wrong. =
 (I'm just restating the issue slightly differently)
>
> given
>
> d[s]/dt =3D f([S])/C         [1]
>
> when
>
> dC/dt =3D g([S])             [2]
>
> Either [1] is the correct formulae or it isn't
> when
> C is varying volume and
> f is a function returning substance/time units and
> g is a function returning volume/time units and
> [S] is the set of all concentrations.
>
> Intuitively I can't see why this formulae is wrong
> but hey what do I know!
>
> My calculus really isn't up to figuring this out!
> sorry I'm a software engineer.  I guess I should know for SBML and all =
that but I don't.
>
> Have we got it wrong?
> Perhaps we have.
>
> I don't have problem in changing SOS to using amount units for the=20
species variables.  However you will still have a problem when a model=20
contains a rate rule in concentration units.  What happens then?=20
> (in that case as na=EFve softy I would multiply by the volume!)
>
> yours Andrew
>
>
>
>> -----Original Message-----
>> From: Rainer Machne [mailto:ra...@tb...]
>> Sent: 13 June 2006 15:09
>> To: Andrew Finney
>> Cc: SOSlib Development
>> Subject: RE: [SOSlib-devel] variable compartment bug[Scanned]
>>
>> Andrew
>>
>>
>> I have added a corrected and more clear version of the example file.
>>
>>
>>> All you need to do is ensure that the initialAmount values
>> are used to
>>> calculate the initialConcentration values again by dividing by the
>>> volume.  Have we implemented that?
>>
>> Yes, the internal SBML ode model only contains
>> initialConcentrations; initialAmounts from the input model
>> have all been converted by dividing by compartment size.
>>
>>
>>> if S1 is in a compartment with volume C then
>>>
>>> d[S1]/dt =3D (f1() + f2() + ... fn()) / C
>>>
>>> f1..fn are the reaction rates which are
>>> expressions that have units substance/time
>>>
>>> f1...fn are functions of the concentrations of the
>>> species [S1]..[Sn]
>>>
>>> I thought that's what we'd implemented.
>>
>> Yes, that is what we have.
>>
>>
>>> Why do you need two sets of values?
>>
>> Ok, I'll try to explain in more detail.
>>
>> I change the notation to
>> S ... amount of molecule S
>> s ... concentration, [S] =3D S/v
>> v ... volume
>>
>>
>> Imagine we start with initialConcentration s(0) =3D 1,
>> and integrate from 0 to time 1.
>>
>> What cvode does is to add the concentration increase ds to
>> the initial
>> concentration:
>>
>> s(t) =3D s(0) + ds
>>
>> if the volume is doubled during that time e.g. by a rate
>> rule, ds should
>> correctly include the changing volume because its part of the ODE.
>>
>> However, s(0)=3D1 has never been corrected for the changing volume!
>>
>> If the ODE ds/dt was 0 during this time, e.g. because of a missing
>> activator of the reaction, s(t) would still change to 0.5,
>> because the
>> volume has doubled.
>>
>> This is not reflected in SOSlib!
>>
>> To the example XML:
>>
>>> Note the initial volume of the compartment is not specified
>> in the xml.
>>
>> Sorry, I tried the model with old version which still had the
>> `missing
>> parameter bug' from last week.
>> See the attached corrected file.
>>
>> The compartment volume increases to 11 because of its rate rule
>> d(volume)/dt =3D + 0.1
>>
>> Substance s1 starts with concentration 1 and is totally
>> consumed by the
>> irreversible reaction
>>
>> S1 -> S2; kineticLaw =3D k+S1
>>
>> which moves all molecules to S2.
>>
>> Substance S2 would have a final concentration of 1, if the
>> compartment
>> still had volume 1, but not for a final volume of 11.
>>
>> The final concentration should be 1/11.
>>
>> The totalConcentration in the example file should also
>> decrease to 1/11.
>>
>>
>> SOSlib and the ODE division by volume only corrects the change of
>> concentration but not the initial concentration, or generally
>> spoken, the
>> concentration of the last time step, which also has decreased.
>>
>> The only solution i can think of, is to define ODEs in
>> substance/time and
>> do the division independently of the ODE system.
>>
>> Rainer
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Tue, 13 Jun 2006, Andrew Finney wrote:
>>
>>> Rainer
>>>
>>> Slow down!!
>>>
>>> I don't actually understand the argument:
>>> why can't you have the ODEs as ODEs of concentrations:
>>>
>>> if S1 is in a compartment with volume C then
>>>
>>> d[S1]/dt =3D (f1() + f2() + ... fn()) / C
>>>
>>> f1..fn are the reaction rates which are
>>> expressions that have units substance/time
>>>
>>> f1...fn are functions of the concentrations of the
>>> species [S1]..[Sn]
>>>
>>> I thought that's what we'd implemented.
>>>
>>> Why do you need two sets of values?
>>>
>>> I would strongly urge we go for the approach is having
>>> one set of values and carefully converting the units as is
>> appropriate.
>>>
>>> fundamentally what's the problem?
>>>
>>> In the SBML you sent the only fly in the ointment
>>> is that the initial value for the species is
>>> expressed in substance units via the initialAmount
>> attribute rather than
>>> the initialConcentration
>>> attribute which is in concentration units.
>>>
>>> All you need to do is ensure that the initialAmount
>>> values are used to calculate the initialConcentration
>> values again by
>>> dividing by the volume.  Have
>>> we implemented that?
>>>
>>> Note the initial volume of the compartment is not specified
>> in the xml.
>>>
>>> yours Andrew
>>>
>>>> -----Original Message-----
>>>> From: sbm...@li...
>>>> [mailto:sbm...@li...] On
>>>> Behalf Of Rainer Machne
>>>> Sent: 13 June 2006 11:42
>>>> To: SOSlib Development
>>>> Subject: [SOSlib-devel] variable compartment bug[Scanned]
>>>>
>>>> Folks
>>>>
>>>> Lukas has identified another serious bug!
>>>>
>>>> SOSlib doesn't support variable compartments.
>>>>
>>>> We initialize sundials with ODEs for concentrations d[A]/dt,
>>>> and sundials calculates [A] + (d[A]/dt)*h, where h is a small
>>>> time step and [A] is the initial condition or the current value.
>>>>
>>>> If we have a variable, e.g time-dependent compartment, then
>>>> d[A]/dt will change with changing compartment because the
>>>> compartment size is part of the right hand side.
>>>>
>>>> However, not only d[A]/dt is dependent on the volume, but
>>>> also [A], i.e.
>>>> the current value in data->value!
>>>>
>>>> The attached example file exemplifies this.
>>>>
>>>> So we actually should use an ODE system in amount/time
>>>> instead of concentration/time, and have a second data->value
>>>> array for concentrations to be used in formula evaluation.
>>>>
>>>> Didn't we discuss this once? I remember that I had started to
>>>> do this (ODEs in amount/time), but then it got more
>>>> complicated then I thought and something else came up.
>>>>
>>>> Can you think of any problems we will run into? Andrew, how
>>>> about the compiling version?
>>>>
>>>> Rainer
>>>>
>>>
>>
>
>
> _______________________________________________
> sbmlsolver-devel mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>

Re: [SOSlib-devel] variable compartment bug[Scanned]

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

Rainer
=20
I think I understand your English argument

my last email was really just a comment on
how you expressed your argument :-)

I don't exactly understand why the math doesn't work.
CVODE solves any correctly defined ODE system
if CVODE produces the wrong results then we've got the formulae wrong.  =
(I'm just restating the issue slightly differently)

given=20

d[s]/dt =3D f([S])/C         [1]

when=20

dC/dt =3D g([S])             [2]

Either [1] is the correct formulae or it isn't
when
C is varying volume and
f is a function returning substance/time units and
g is a function returning volume/time units and
[S] is the set of all concentrations. =20

Intuitively I can't see why this formulae is wrong
but hey what do I know!

My calculus really isn't up to figuring this out!
sorry I'm a software engineer.  I guess I should know for SBML and all =
that but I don't.

Have we got it wrong?
Perhaps we have.

I don't have problem in changing SOS to using amount units for the =
species variables.  However you will still have a problem when a model =
contains a rate rule in concentration units.  What happens then?
(in that case as na=EFve softy I would multiply by the volume!)

yours Andrew



> -----Original Message-----
> From: Rainer Machne [mailto:ra...@tb...]=20
> Sent: 13 June 2006 15:09
> To: Andrew Finney
> Cc: SOSlib Development
> Subject: RE: [SOSlib-devel] variable compartment bug[Scanned]
>=20
> Andrew
>=20
>=20
> I have added a corrected and more clear version of the example file.
>=20
>=20
> > All you need to do is ensure that the initialAmount values=20
> are used to=20
> > calculate the initialConcentration values again by dividing by the=20
> > volume.  Have we implemented that?
>=20
> Yes, the internal SBML ode model only contains=20
> initialConcentrations; initialAmounts from the input model=20
> have all been converted by dividing by compartment size.
>=20
>=20
> > if S1 is in a compartment with volume C then
> >
> > d[S1]/dt =3D (f1() + f2() + ... fn()) / C
> >
> > f1..fn are the reaction rates which are
> > expressions that have units substance/time
> >
> > f1...fn are functions of the concentrations of the
> > species [S1]..[Sn]
> >
> > I thought that's what we'd implemented.
>=20
> Yes, that is what we have.
>=20
>=20
> > Why do you need two sets of values?
>=20
> Ok, I'll try to explain in more detail.
>=20
> I change the notation to
> S ... amount of molecule S
> s ... concentration, [S] =3D S/v
> v ... volume
>=20
>=20
> Imagine we start with initialConcentration s(0) =3D 1,
> and integrate from 0 to time 1.
>=20
> What cvode does is to add the concentration increase ds to=20
> the initial=20
> concentration:
>=20
> s(t) =3D s(0) + ds
>=20
> if the volume is doubled during that time e.g. by a rate=20
> rule, ds should
> correctly include the changing volume because its part of the ODE.
>=20
> However, s(0)=3D1 has never been corrected for the changing volume!
>=20
> If the ODE ds/dt was 0 during this time, e.g. because of a missing=20
> activator of the reaction, s(t) would still change to 0.5,=20
> because the=20
> volume has doubled.
>=20
> This is not reflected in SOSlib!
>=20
> To the example XML:
>=20
> > Note the initial volume of the compartment is not specified=20
> in the xml.
>=20
> Sorry, I tried the model with old version which still had the=20
> `missing=20
> parameter bug' from last week.
> See the attached corrected file.
>=20
> The compartment volume increases to 11 because of its rate rule
> d(volume)/dt =3D + 0.1
>=20
> Substance s1 starts with concentration 1 and is totally=20
> consumed by the=20
> irreversible reaction
>=20
> S1 -> S2; kineticLaw =3D k+S1
>=20
> which moves all molecules to S2.
>=20
> Substance S2 would have a final concentration of 1, if the=20
> compartment=20
> still had volume 1, but not for a final volume of 11.
>=20
> The final concentration should be 1/11.
>=20
> The totalConcentration in the example file should also=20
> decrease to 1/11.
>=20
>=20
> SOSlib and the ODE division by volume only corrects the change of=20
> concentration but not the initial concentration, or generally=20
> spoken, the=20
> concentration of the last time step, which also has decreased.
>=20
> The only solution i can think of, is to define ODEs in=20
> substance/time and=20
> do the division independently of the ODE system.
>=20
> Rainer
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> On Tue, 13 Jun 2006, Andrew Finney wrote:
>=20
> > Rainer
> >
> > Slow down!!
> >
> > I don't actually understand the argument:
> > why can't you have the ODEs as ODEs of concentrations:
> >
> > if S1 is in a compartment with volume C then
> >
> > d[S1]/dt =3D (f1() + f2() + ... fn()) / C
> >
> > f1..fn are the reaction rates which are
> > expressions that have units substance/time
> >
> > f1...fn are functions of the concentrations of the
> > species [S1]..[Sn]
> >
> > I thought that's what we'd implemented.
> >
> > Why do you need two sets of values?
> >
> > I would strongly urge we go for the approach is having
> > one set of values and carefully converting the units as is=20
> appropriate.
> >
> > fundamentally what's the problem?
> >
> > In the SBML you sent the only fly in the ointment
> > is that the initial value for the species is
> > expressed in substance units via the initialAmount=20
> attribute rather than
> > the initialConcentration
> > attribute which is in concentration units.
> >
> > All you need to do is ensure that the initialAmount
> > values are used to calculate the initialConcentration=20
> values again by
> > dividing by the volume.  Have
> > we implemented that?
> >
> > Note the initial volume of the compartment is not specified=20
> in the xml.
> >
> > yours Andrew
> >
> >> -----Original Message-----
> >> From: sbm...@li...
> >> [mailto:sbm...@li...] On
> >> Behalf Of Rainer Machne
> >> Sent: 13 June 2006 11:42
> >> To: SOSlib Development
> >> Subject: [SOSlib-devel] variable compartment bug[Scanned]
> >>
> >> Folks
> >>
> >> Lukas has identified another serious bug!
> >>
> >> SOSlib doesn't support variable compartments.
> >>
> >> We initialize sundials with ODEs for concentrations d[A]/dt,
> >> and sundials calculates [A] + (d[A]/dt)*h, where h is a small
> >> time step and [A] is the initial condition or the current value.
> >>
> >> If we have a variable, e.g time-dependent compartment, then
> >> d[A]/dt will change with changing compartment because the
> >> compartment size is part of the right hand side.
> >>
> >> However, not only d[A]/dt is dependent on the volume, but
> >> also [A], i.e.
> >> the current value in data->value!
> >>
> >> The attached example file exemplifies this.
> >>
> >> So we actually should use an ODE system in amount/time
> >> instead of concentration/time, and have a second data->value
> >> array for concentrations to be used in formula evaluation.
> >>
> >> Didn't we discuss this once? I remember that I had started to
> >> do this (ODEs in amount/time), but then it got more
> >> complicated then I thought and something else came up.
> >>
> >> Can you think of any problems we will run into? Andrew, how
> >> about the compiling version?
> >>
> >> Rainer
> >>
> >
>=20

Re: [SOSlib-devel] variable compartment bug[Scanned]

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

Andrew


I have added a corrected and more clear version of the example file.


> All you need to do is ensure that the initialAmount
> values are used to calculate the initialConcentration values again by
> dividing by the volume.  Have
> we implemented that?

Yes, the internal SBML ode model only contains initialConcentrations;
initialAmounts from the input model have all been converted by dividing by 
compartment size.


> if S1 is in a compartment with volume C then
>
> d[S1]/dt = (f1() + f2() + ... fn()) / C
>
> f1..fn are the reaction rates which are
> expressions that have units substance/time
>
> f1...fn are functions of the concentrations of the
> species [S1]..[Sn]
>
> I thought that's what we'd implemented.

Yes, that is what we have.


> Why do you need two sets of values?

Ok, I'll try to explain in more detail.

I change the notation to
S ... amount of molecule S
s ... concentration, [S] = S/v
v ... volume


Imagine we start with initialConcentration s(0) = 1,
and integrate from 0 to time 1.

What cvode does is to add the concentration increase ds to the initial 
concentration:

s(t) = s(0) + ds

if the volume is doubled during that time e.g. by a rate rule, ds should
correctly include the changing volume because its part of the ODE.

However, s(0)=1 has never been corrected for the changing volume!

If the ODE ds/dt was 0 during this time, e.g. because of a missing 
activator of the reaction, s(t) would still change to 0.5, because the 
volume has doubled.

This is not reflected in SOSlib!

To the example XML:

> Note the initial volume of the compartment is not specified in the xml.

Sorry, I tried the model with old version which still had the `missing 
parameter bug' from last week.
See the attached corrected file.

The compartment volume increases to 11 because of its rate rule
d(volume)/dt = + 0.1

Substance s1 starts with concentration 1 and is totally consumed by the 
irreversible reaction

S1 -> S2; kineticLaw = k+S1

which moves all molecules to S2.

Substance S2 would have a final concentration of 1, if the compartment 
still had volume 1, but not for a final volume of 11.

The final concentration should be 1/11.

The totalConcentration in the example file should also decrease to 1/11.


SOSlib and the ODE division by volume only corrects the change of 
concentration but not the initial concentration, or generally spoken, the 
concentration of the last time step, which also has decreased.

The only solution i can think of, is to define ODEs in substance/time and 
do the division independently of the ODE system.

Rainer










On Tue, 13 Jun 2006, Andrew Finney wrote:

> Rainer
>
> Slow down!!
>
> I don't actually understand the argument:
> why can't you have the ODEs as ODEs of concentrations:
>
> if S1 is in a compartment with volume C then
>
> d[S1]/dt = (f1() + f2() + ... fn()) / C
>
> f1..fn are the reaction rates which are
> expressions that have units substance/time
>
> f1...fn are functions of the concentrations of the
> species [S1]..[Sn]
>
> I thought that's what we'd implemented.
>
> Why do you need two sets of values?
>
> I would strongly urge we go for the approach is having
> one set of values and carefully converting the units as is appropriate.
>
> fundamentally what's the problem?
>
> In the SBML you sent the only fly in the ointment
> is that the initial value for the species is
> expressed in substance units via the initialAmount attribute rather than
> the initialConcentration
> attribute which is in concentration units.
>
> All you need to do is ensure that the initialAmount
> values are used to calculate the initialConcentration values again by
> dividing by the volume.  Have
> we implemented that?
>
> Note the initial volume of the compartment is not specified in the xml.
>
> yours Andrew
>
>> -----Original Message-----
>> From: sbm...@li...
>> [mailto:sbm...@li...] On
>> Behalf Of Rainer Machne
>> Sent: 13 June 2006 11:42
>> To: SOSlib Development
>> Subject: [SOSlib-devel] variable compartment bug[Scanned]
>>
>> Folks
>>
>> Lukas has identified another serious bug!
>>
>> SOSlib doesn't support variable compartments.
>>
>> We initialize sundials with ODEs for concentrations d[A]/dt,
>> and sundials calculates [A] + (d[A]/dt)*h, where h is a small
>> time step and [A] is the initial condition or the current value.
>>
>> If we have a variable, e.g time-dependent compartment, then
>> d[A]/dt will change with changing compartment because the
>> compartment size is part of the right hand side.
>>
>> However, not only d[A]/dt is dependent on the volume, but
>> also [A], i.e.
>> the current value in data->value!
>>
>> The attached example file exemplifies this.
>>
>> So we actually should use an ODE system in amount/time
>> instead of concentration/time, and have a second data->value
>> array for concentrations to be used in formula evaluation.
>>
>> Didn't we discuss this once? I remember that I had started to
>> do this (ODEs in amount/time), but then it got more
>> complicated then I thought and something else came up.
>>
>> Can you think of any problems we will run into? Andrew, how
>> about the compiling version?
>>
>> Rainer
>>
>

Re: [SOSlib-devel] wrong AST_FUNCTION_ABS implementation

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

On Tue, 13 Jun 2006, Stefan Mueller wrote:

> hi rainer!
>
> you are right. currently the implementaion is wrong.
> it should be as it's written in the comment.
> f(x)=abs(a(x)) => f' = sig(a)*a'

sig(a) is not an ASTNode type, so I guess we need to construct a piecewise 
function:

if a < 0: -1
if a > 0: +1

What if a = 0?


The next problem then is, that our piecewise implementation is also not 
generally valid.

   case AST_FUNCTION_PIECEWISE:
     if ( evaluateAST(child(n,0),data) )
       result = evaluateAST(child(n,1),data);
     else
       result = evaluateAST(child(n,2),data);

Which is only valid for piecewise/otherwise combinations, but not for more 
then one `piece'.

See e.g
http://www.zvon.org/xxl/MathML/Output/el_piecewise.html
and click example repository for two examples.

Rainer



>
> don't worry about the discontinuity at x=0! :)
>
> cheers, s
>
>
> Am Freitag 09 Juni 2006 17:46 schrieb Rainer Machne:
>> Hi Stefan
>>
>> I am currently going through the code, implementing the style convention
>> and getting familiar with SOSlib again :-)
>>
>> in differentiateAST we have the lines
>>
>>      case AST_FUNCTION_ABS:             /** ABS: WRONG */
>>        /* f(x)=abs(a(x)) => f' = sig(a)*a'
>>  	  WRONG: CAN RESULT IN A DISCONTINUOUS FUNCTION! */
>>        ASTNode_setType(fprime, ASTNode_getType(f)); /* WRONG !!! */
>>        ASTNode_addChild(fprime, differentiateAST(ASTNode_getChild(f,0),x));
>>        break;
>>
>> So it's actually not doing what it claims in the comment, and also there
>> are these uppercase WRONG warnings.
>>
>> What should we do about that. Should we implement it as written in the
>> comment?
>>
>> Rainer
>>
>>
>>
>>
>> _______________________________________________
>> sbmlsolver-devel mailing list
>> sbm...@li...
>> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>

Re: [SOSlib-devel] variable compartment bug[Scanned]

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

Rainer

Slow down!!

I don't actually understand the argument:
why can't you have the ODEs as ODEs of concentrations:

if S1 is in a compartment with volume C then

d[S1]/dt =3D (f1() + f2() + ... fn()) / C

f1..fn are the reaction rates which are=20
expressions that have units substance/time

f1...fn are functions of the concentrations of the
species [S1]..[Sn]

I thought that's what we'd implemented.

Why do you need two sets of values?

I would strongly urge we go for the approach is having
one set of values and carefully converting the units as is appropriate.

fundamentally what's the problem?

In the SBML you sent the only fly in the ointment
is that the initial value for the species is
expressed in substance units via the initialAmount attribute rather than
the initialConcentration
attribute which is in concentration units.

All you need to do is ensure that the initialAmount
values are used to calculate the initialConcentration values again by
dividing by the volume.  Have
we implemented that?

Note the initial volume of the compartment is not specified in the xml.

yours Andrew

> -----Original Message-----
> From: sbm...@li...=20
> [mailto:sbm...@li...] On=20
> Behalf Of Rainer Machne
> Sent: 13 June 2006 11:42
> To: SOSlib Development
> Subject: [SOSlib-devel] variable compartment bug[Scanned]
>=20
> Folks
>=20
> Lukas has identified another serious bug!
>=20
> SOSlib doesn't support variable compartments.
>=20
> We initialize sundials with ODEs for concentrations d[A]/dt,=20
> and sundials calculates [A] + (d[A]/dt)*h, where h is a small=20
> time step and [A] is the initial condition or the current value.
>=20
> If we have a variable, e.g time-dependent compartment, then=20
> d[A]/dt will change with changing compartment because the=20
> compartment size is part of the right hand side.
>=20
> However, not only d[A]/dt is dependent on the volume, but=20
> also [A], i.e.=20
> the current value in data->value!
>=20
> The attached example file exemplifies this.
>=20
> So we actually should use an ODE system in amount/time=20
> instead of concentration/time, and have a second data->value=20
> array for concentrations to be used in formula evaluation.
>=20
> Didn't we discuss this once? I remember that I had started to=20
> do this (ODEs in amount/time), but then it got more=20
> complicated then I thought and something else came up.
>=20
> Can you think of any problems we will run into? Andrew, how=20
> about the compiling version?
>=20
> Rainer
>=20