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