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

Re: [SOSlib-devel] Request for additional function in api interface.

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

Hi,

> So I just added set->Indefinitely == 0; to be safe, and made this function
> part of the API.

This was actually a bug. The indefinetely setting didn't work anymore when 
afterwards CvodeSettings_setTime was called. Sorry for that. A correct 
version is in CVS.

However, this brings up this up again:

Having CvodeSettings_setTimeStep in the API
> ... might either
> a) cause conflicts with the indefinitely setting or
> b) cause potential problems when a user sets a time series with starting
> values other then 0.

But I guess it shouldn't be a problem. The first time in the passed array 
will be the next time step for indefinite integration and the user has to 
know about consequences of indefinite integration anywas.

Rainer


On Wed, 6 Sep 2006, Rainer Machne wrote:

> On Tue, 5 Sep 2006, W Eryk Wolski wrote:
>
>> Hi,
>>
>> Can we move the function
>> static int CvodeSettings_setTimeSeries(cvodeSettings_t *set, double
>> *timeseries, int PrintStep);
>>
>> to the API interface please? If one wants to set a whole time series
>> it is much more straightforward to do this using this function than
>> using:
>>
>> SBML_ODESOLVER_API int CvodeSettings_setTimeStep(cvodeSettings_t *,
>> int, double);
>> Especially that in case of this function it is not clear how to
>> specify the length of the time series to set first.
>>
>>
>> All the best.
>> Eryk
>
> Hi Eryk,
>
> Your point is good, but I remember that there was a reason to make this
> function "static/private". Unfortunately, I currently don't remember what
> the reason was ...
>
> It might either
> a) cause conflicts with the indefinitely setting or
> b) cause potential problems when a user sets a time series with starting
> values other then 0.
>
> However b seems to be avoided anyways because it is set to 0 and the
> first value of the passed time series is ignored.
>
> So I just added set->Indefinitely == 0; to be safe, and made this function
> part of the API.
>
> Or are there any concerns? Can anyone think of another reason to have this
> function private?
> Is it un-safe to have a function where two values must correspond to each
> other (PrintStep is the size of the array timeseries)?
>
> James, would you also want to move CvodeSettings_setAdjTimeSeries to the
> API?
>
> If no objections are brought up, I can submit these changes to CVS.
>
> Rainer
>
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> sbmlsolver-devel mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>

[SOSlib-devel] construction of jacobian and sensitivity matrices

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

Hi Andrew

we have finally started work on SOSlib again, first implementing 
sensitivity analysis for selected parameters and also for sensitivities 
with respect to initial conditions.

I have a question:
Can you remember the reason why jacobian and sensitivity matrices are 
constructed in the createCVODE(S)SolverStructures and not e.g. in 
CvodeData_initialize? Was there a reason for that? E.g. maybe problems 
with the using the optimized ODEs in cvodeData.

The problem is creating structures either at time 0 or after an event.

Rainer

[SOSlib-devel] sens.anal. for selected parameters

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

Hi,

I have just commited code that allows to select parameters for 
sensitivity analysis. It seems to work fine so far and does not break 
interfaces. The old version, i.e. sens.anal. for all constants of the 
model, is now a default case.

Tomorrow I will add the capability for sensitivity analysis for initial 
conditions. James discovered that this should be a straight-forward 
extension to the existing code.

Eryk: you might be interested in that, as these sensitivities to initial 
  conditions are used for the Fisher information matrix, right?
We so far didn't know that it would be such an easy extension to current 
sens.analysis. If you have implemented a separate capability for 
calculating these sensitivities, maybe you can help us verify results.

cheers,
Rainer

Re: [SOSlib-devel] Request for help with a multicompartment problem

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

Mike

you wrote:

> More generally, I think you would agree that modelers should
> be able to express a compound rate expression that involves
> whatever compartmental organization they feel is appropriate
> for their problem.  (And indeed, Nicolas will attest to the
> fact that models in the wild do this.)
> 

I agree.  But we don't need to get stressed if they screw up the units!

yours
Andrew Finney  

> -----Original Message-----
> From: Michael Hucka [mailto:mh...@ca...] 
> Sent: 11 September 2006 08:26
> To: Andrew Finney
> Cc: 'Rainer Machne'; 'Nicolas Le Novere'; 'SOSlib Development'
> Subject: RE: Request for help with a multicompartment problem
> 
> Hi Andrew,
> 
>   afinney> describes a phenomena that only really works in a
>   afinney> single compartment.  i.e. when two species are in
>   afinney> the same compartment and therefore can freely
>   afinney> react with each other the rate of reaction is
>   afinney> proportional to the concentrations of the
>   afinney> species.
> 
> I suspect Nicolas will say something about it too, but I
> want to mention I got an email from Bob Phair on the same
> question, and he entirely contradicted the claim that this
> is an unusual situation.  In his words, "The situation you
> describe actually occurs frequently. I don't see anything
> weird here", and goes on to give an example of extracellular
> signal molecule binding to membrane receptors where you have
> to deal with separate volumes.
> 
> (His solution to the problem was change the rate constant.
> I'll ask if I can forward his reply around.)
> 
> What may be a bit confusing is the rate law I used,
> mass-action, has assumptions about molecular interactions.
> If you remove that, perhaps it won't require thinking that
> the reactants have to be in the same space.
> 
> More generally, I think you would agree that modelers should
> be able to express a compound rate expression that involves
> whatever compartmental organization they feel is appropriate
> for their problem.  (And indeed, Nicolas will attest to the
> fact that models in the wild do this.)
> 
> MH
> 

[SOSlib-devel] piecewise ... (fwd)

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

Hi All,

for the record, and for anyone interested in bug fixing :), i forward this 
email to the list.

Again or still, we seem to have a piecewise bug. The reason for the 
strange behaviour described by Nicolas below is unclear.

A piecewise expression used in an assignment rule contains the "time". The 
respective expression seems to be set true at time 57... while it should 
only become true at time 60.

The only suspicion I have is that the assignment rule is not updated 
correctly and that the rule still has some value which it took in an 
internal CVODE evaluation when it internally was already at time 60 for 
evaluating f.
Andrew, is it possible that your priority for assignment rule evaluation 
doesn't account for rules that contain "time"?

I will look at it next week but maybe you have an idea.

Rainer


---------- Forwarded message ----------
Date: Tue, 12 Sep 2006 18:03:20 +0100 (BST)
From: Nicolas Le Novere <le...@eb...>
To: ra...@tb...
Subject: piecewise ...

Dear Rainer,

We are still working on the problematic model that led us to ask-you
to modify SBMLodeSolver for piecewise functions (we are doing other
things as well, don't worry :-)

I attach a model that should be fine. I tested it without rule, and
with only the assignment rule for Sstar. In both case, the model
worked perfectly. Now, with the piecewise function (only one piece for
the moment), we encounter all kinds of problems:

For some reason, at t=57, Sstar jumps from 0.012 to 14.45, the value
it will take after the piecewise jump for calcium at t>60. But the
calcium is still unchanged!

Then, after t=60, even if Sstar increased 0.012 to 14.45, the
reactions involving it remain unchanged, until t=62.44.

Is-it a problem of output only? Is-it a problem in the patching of
SBMLodeSolver?

I join the SBML and the output of

odeSolver -w --time 100 --printstep 1000 
dAlcantara_Bidirectional_Plasticity_CorrectedOnePiece.xml

(renamed .clean to go through the mail filters)

-- 
Nicolas LE NOVERE,  Computational Neurobiology,
EMBL-EBI, Wellcome-Trust Genome Campus, Hinxton, Cambridge, CB10 1SD, UK
Tel: +44(0)1223 494 521,  Fax: +44(0)1223 494 468,  Mob: +33(0)689218676
http://www.ebi.ac.uk/~lenov, AIM: nlenovere,  MSN: nle...@ho...

Re: [SOSlib-devel] Request for help with a multicompartment problem

[Michael H. <mh...@ca...>]

Can I send around your replies to other people?  I mailed
some other people about the same question and would like to
construct a compilation of everyone's replies then mail them
to everyone again.

The replies are interesting in their divergence...

MH

Re: [SOSlib-devel] Request for help with a multicompartment problem

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

Hi Michael,

Michael Hucka wrote:


>... and goes on to give an example of extracellular
>signal molecule binding to membrane receptors where you have
>to deal with separate volumes.
>
>(His solution to the problem was change the rate constant.
>I'll ask if I can forward his reply around.)
>

I haven't read through all the messages yet, but we ran across this
problem  when trying to translate the Schoeberl et al. 2001 model to
SBML. Tell me if this initial comment already helps you, otherwise I
will try to respond in more detail later.

d[A]/dt = -k * [A] * [B]

If A and B are ligand and receptor, and thus A is soluble and 
extracellular
while B is in a membrane compartment, the reaction itself still happens in
A's compartment!! B's reacting domain is also in this compartment! If
in the rest of the model B is described in concentrations in membrane or
cytosol, the modeller will have to convert B's concentration to 
extracellular by a volume ratio Vb/Va and the equation would read


d[A]/dt = -k * [A] * Vb/Va * [B]

... and I think it's the modeller's job to write the kinetic law this way.

I agree with Andrew that in general a reaction between species in 
different compartments makes no physical sense and therefor there can also 
not be correct rate law for such a situation.

Sorry, if this misses the topic our your question and is not really 
helpful or if the above example is also wrong and already covered in your 
previous messages. I'll go through the messages later. But let me know if 
it helps.

Rainer

Re: [SOSlib-devel] Request for help with a multicompartment problem

[Nicolas Le N. <le...@eb...>]

On Mon, 11 Sep 2006, Andrew Finney wrote:

> Assuming the issue is just how to create an encoding in SBML for
> multicomparment models
> and not how to map from SBML to ODEs...
>
> I'd just like to point out one obvious point...
>
> an equation like
>
> d[C]/dt = k * [A] * [B]
>
> describes a phenomena that only really works in a single compartment.
> i.e. when two species are in the same compartment and therefore can freely
> react with each
> other the rate of reaction is proportional to the concentrations of the
> species.
>
> if A B and C are not in the same compartment the equation doesn't make any
> physical sense to describe the interactions
>
> in that case any chemical equation A + B -> C
> has be decomposed into its constituent transport and conversation components
> before you can move forward,

But that is the point. Developing a model implies a balance of
abstraction Vs. biological exactitude. I recently submitted a paper
describing a model with 159 reactions. Two-third of them involve
various states of just one molecule. On the contrary, the remaining
reactions are mainly phenomenological descriptions of all the others
participants. And that's fine. Because we don't care much about
them. We just want them to behave as we think they are in the cell.

If that suits me, I can perfectly model degradation of mRNA using a
RNAse in the cytosol and the mRNA in the nucleus, without modeling the
transport of RNA. No referee will reject my model, except if it deals
specifically with RNA degration (funny enough regarding the model
cited above, we braced ourselves against the referee's criticisms on
the way we modeled second-knives and prepared alternative version of
the model. But none of the three referees - who did a very thorough
job and required a huge number of modifications - even mentioned the
issus).

IMHO, it is not our job, as SBML developers, to decide how a modeller
should formulate the model.


-- 
Nicolas LE NOVERE,  Computational Neurobiology,
EMBL-EBI, Wellcome-Trust Genome Campus, Hinxton, Cambridge, CB10 1SD, UK
Tel: +44(0)1223 494 521,  Fax: +44(0)1223 494 468,  Mob: +33(0)689218676
http://www.ebi.ac.uk/~lenov, AIM: nlenovere,  MSN: nle...@ho...

Re: [SOSlib-devel] Request for help with a multicompartment problem

[Michael H. <mh...@ca...>]

Hi Andrew,

  afinney> describes a phenomena that only really works in a
  afinney> single compartment.  i.e. when two species are in
  afinney> the same compartment and therefore can freely
  afinney> react with each other the rate of reaction is
  afinney> proportional to the concentrations of the
  afinney> species.

I suspect Nicolas will say something about it too, but I
want to mention I got an email from Bob Phair on the same
question, and he entirely contradicted the claim that this
is an unusual situation.  In his words, "The situation you
describe actually occurs frequently. I don't see anything
weird here", and goes on to give an example of extracellular
signal molecule binding to membrane receptors where you have
to deal with separate volumes.

(His solution to the problem was change the rate constant.
I'll ask if I can forward his reply around.)

What may be a bit confusing is the rate law I used,
mass-action, has assumptions about molecular interactions.
If you remove that, perhaps it won't require thinking that
the reactants have to be in the same space.

More generally, I think you would agree that modelers should
be able to express a compound rate expression that involves
whatever compartmental organization they feel is appropriate
for their problem.  (And indeed, Nicolas will attest to the
fact that models in the wild do this.)

MH

Re: [SOSlib-devel] Request for help with a multicompartment problem

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

Folks

Assuming the issue is just how to create an encoding in SBML for
multicomparment models
and not how to map from SBML to ODEs...

I'd just like to point out one obvious point...

an equation like 

d[C]/dt = k * [A] * [B]

describes a phenomena that only really works in a single compartment.
i.e. when two species are in the same compartment and therefore can freely
react with each
other the rate of reaction is proportional to the concentrations of the
species.

if A B and C are not in the same compartment the equation doesn't make any
physical sense to describe the interactions

in that case any chemical equation A + B -> C
has be decomposed into its constituent transport and conversation components
before you can move forward,

As far as SBML is concerned there 2 ways to go either you formulate a
complex rate equation which enables you to fold in the transport and
conversion components together or
you decompose the SBML reaction into simpler ones

Must go to work now

Bye

Andrew

[SOSlib-devel] Request for help with a multicompartment problem

[Michael H. <mh...@ca...>]

Rainer and the rest,

Thanks for finding those errors in the examples in the SBML
spec; we'll try to get them out.

But since you have been thinking about this topic, I'd like
to ask you how you think the following class of problems can
be solved.  It has been confounding Nicolas and myself.

Suppose we have a reaction system consisting of 3
compartments, with species A in Va, B in Vb, and C in Vc
(I'm using the volumes as the names of the compartments),
and the reaction is

   A + B -> C

The compartments have constant volume; no varying volumes
here.  Suppose further that the reaction is said to obey the
simplest possible kind of kinetics, a kind of mass action
(but a weird one because multiple compartments are
involved).  So let's say the rate is

  k * [A] * [B]

Here, k must have units of a 2nd order rate constant, which
is 1/(Molar * time) = (volume)/(substance*time).  As initial
values, we might be given the values of concentrations [A],
[B], [C], or we might be given the substance amounts; it
won't matter as we'll see below.  The key point is that the
reactants are in different compartments.

Now we want to construct the ODEs.

First let's start naively just to make sure all the grounds
are covered.  The first attempt we might make is to say that
the rates of change are like in traditional kinetics:

  d[A]/dt = -k * [A] * [B]
  d[B]/dt = -k * [A] * [B]
  d[C]/dt =  k * [A] * [B]

But this can easily be shown to be wrong.  Borrowing an
example that Nicolas has written for the l2v2 spec, let's
say that volume Vc = 2*Va (i.e., Vc is twice the volume of
Va).  Then if we calculate the change of substance amounts
(moles or items) in compartments Va and Vc (and here I'm
using "A" to stand for the amount of substance of species A,
"C" to stand for the amount of substance of species C):

  dA/dt = Va*d[A]/dt = Va * (-k * [A] * [B]^2)

  dC/dt = Vc*d[C]/dt = Vc * (k * [A] * [B]^2)
                     = 2 * Va * (k * [A] * [B]^2)

So we just created matter out of nothing.  This simply
proves what we already knew, which is that we have to
express the rate in terms of substance changes, not
concentration changes.

OK, fine, so let's try to do that.  Since we know the
compartment volumes and we can know the concentrations of
each species, we have the relationships

  [A] = A/Va
  [B] = B/Vb
  [C] = C/Vc

We then substitute this into the ODEs:

  d[A]/dt = -k * (A/Va) * (B/Vb)
  d[B]/dt = -k * (A/Va) * (B/Vb)
  d[C]/dt =  k * (A/Va) * (B/Vb)

So far this is perfectly valid, but it didn't help anything;
the overall expressions are still in terms of
concentrations.  We need to make them to be about species
amount, not concentrations.

But how?

Attempt #1: Multiply each ODE by the volume in which that
species is located.  Let's take for example d[C]/dt, and
multiply it by the volume in which [C] is located:

  dC/dt = Vc*d[C]/dt = k * (A/Va) * (B/Vb) * Vc

This seems reasonable; after all, C is located in Vc, and
Vc*[C] must give me number of molecules of C.  But it can't
be right.  Suppose I change the model by doubling the size
of Vc, without changing anything else in the system.
According to the above, the rate of appearance of molecules
of C will double if I do that, which is impossible because
actually the number of molecules must be solely determined
by the reactants.

Attempt #2: The conclusion from the above must be that
multiplying by Vc is the wrong way around.  The core rate
expression must be reformulated in terms of substance per
time, not concentration per time, and *then* concentrations
can be made out of it by dividing by the volumes as needed.
So let's try to do that.

  new rate expr = k * ([A]*Va) * ([B]*Vb)

This gets rid of the concentration terms, but now the units
are wrong, because they are (volume * substance)/time rather
than substance/time.  Hmmm.  Could this be a clue?  Maybe we
just need to divide by a volume?  That seems promising.  So:

  dA/dt = ( -k * ([A]*Va) * ([B]*Vb) )/Va
  dB/dt = ( -k * ([A]*Va) * ([B]*Vb) )/Vb
  dC/dt = (  k * ([A]*Va) * ([B]*Vb) )/Vc

The units look right.  But wait, this has the same problem
as before: if Vc changes and nothing else in the system
changes, the rate of appearance of C will change.

Attempt #3: Maybe we simply divided by the wrong volume in
the equations above; maybe it should be always Va or Vb.
Oh, but, there are two choices: Va and Vb.  If we can only
use one, how do we pick which one we use?

Attempt #4: Ok, so the volume division idea isn't working.
What if the issue is not about dividing by volumes, but
instead, the problem is that the units of k need to be
changed?  Maybe what we really need is

  dA/dt = -k' * ([A]*Va) * ([B]*Vb)
  dB/dt = -k' * ([A]*Va) * ([B]*Vb)
  dC/dt =  k' * ([A]*Va) * ([B]*Vb)

Then k' can be used to sort out the units.  Except.... what
*should* be the correction applied to k?  How can we create
k' systematically?  What if the rate law is something
entirely different -- without a k', or with other constants?
What will the correction be then?


So at this point, we're stuck.  The conclusion must be one
of the following:

  Option (a): Conclude that attempt #4 is the right way, and
    we need to work out how to construct a proper correction
    term for the general case.

  Option (b): Conclude that there is a fundamental error in
    one or more of the attempts #1-4, or there is another
    way out.

  Option (c): Conclude that we must declare the situation
    impossible and require that all reactants must be in the
    same compartment.

Unfortunately, Nicolas points out that (c) is violated by
some existing models -- they already use multiple
compartments for reactants -- so people must believe it's
doable.  Option (c) is not a way out.

What is your opinion?  What is the solution?  How should
this multicompartment model be solved?  

MH

Re: [SOSlib-devel] IntegratorInstance_reset

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

On Wed, 6 Sep 2006, James Lu wrote:

> hi Rainer:
>
> In looking at the adjoint code again, I saw that IntegratorInstance_reset
> calls  IntegratorInstance_set, which consists of calls:  CvodeData_initialize
> and IntegratorInstance_initializeSolver.
>
> I just found that the bug in running examples/adj_sensitivity.c is associated
> with the IntegratorInstance_set called after the forward phase. In fact, what
> is need is IntegratorInstance_initializeSolver:  CvodeData_initialize
> shouldn't be called before the adjoint phase starts.
>
> Could you tell me circumstances in which IntegratorInstance_reset is used?
> And is it possible (perhaps after some reorganization) to have access to
> simply IntegratorInstance_initializeSolver...what is the best way to go about
> it?
>
> thanks,
>
> James

Hi James,

> circumstances in which IntegratorInstance_reset is used?

It is used in iterative forward integration runs, i.e. re-initialization 
of the solver to initial conditions. After one integration the calling 
application can either use a completely new settings structure, or just 
change some settings of the current settings. Then _reset will call 
CvodeData_initialize to get all initial conditions from the odeModel and 
then re-init the solver structures.

As discussed with you in private emails, it might be a good idea to 
untangle a first creation of a solver and the reinitialization.
The latter is required in two cases:

a) a completely new run of the solver, starting with initial conditions at 
time zero, for this _reset and _set functions can be used
b) cases where either the calling application (_setVariableValue) or an 
event changes an ODE variable during one integration run

Actually, once a CVODE solver structure is created from an SBML/odeModel, 
it can be used as it is forever and only requires CVodeReinit, because the 
dimensionality NEQ of the problem should not change.

The reason this is mixed is mainly because we found the Reinit function 
only some months ago.

This is currently also true for sensitivity analysis, because its 
dimension NSENS also never can change, as it is done for all constants of 
the model. However, we plan to have a custom sensitivity analysis, where 
parameters can be chosen by the calling application.
So the sensitivity code requires a different handling and cannot just be 
reinit-ed during runs because NSENS might change.

Rainer

[SOSlib-devel] IntegratorInstance_reset

[James Lu <jam...@oe...>]

hi Rainer:

In looking at the adjoint code again, I saw that IntegratorInstance_reset 
calls  IntegratorInstance_set, which consists of calls:  CvodeData_initialize 
and IntegratorInstance_initializeSolver.

I just found that the bug in running examples/adj_sensitivity.c is associated 
with the IntegratorInstance_set called after the forward phase. In fact, what  
is need is IntegratorInstance_initializeSolver:  CvodeData_initialize 
shouldn't be called before the adjoint phase starts. 

Could you tell me circumstances in which IntegratorInstance_reset is used?
And is it possible (perhaps after some reorganization) to have access to 
simply IntegratorInstance_initializeSolver...what is the best way to go about 
it?

thanks,

James

Re: [SOSlib-devel] Request for additional function in api interface.

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

The functions
  CvodeSettings_setTimeSeries
and
  CvodeSettings_setAdjTimeSeries
have been moved to the API. Please update your CVS.

Rainer


On Tue, 5 Sep 2006, W Eryk Wolski wrote:

> Hi,
>
> Can we move the function
> static int CvodeSettings_setTimeSeries(cvodeSettings_t *set, double
> *timeseries, int PrintStep);
>
> to the API interface please? If one wants to set a whole time series
> it is much more straightforward to do this using this function than
> using:
>
> SBML_ODESOLVER_API int CvodeSettings_setTimeStep(cvodeSettings_t *,
> int, double);
> Especially that in case of this function it is not clear how to
> specify the length of the time series to set first.
>
>
> All the best.
> Eryk
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> sbmlsolver-devel mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>

Re: [SOSlib-devel] Request for additional function in api interface.

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

Ok, I said something wrong in my email before:

> However b seems to be avoided anyways because it is set to 0 and the
> first value of the passed time series is ignored.

That's NOT true. Actually the first value of the passed timeseries will be 
the first output time and the internal time array is one double bigger as 
the passed one.
Maybe this was also a reason to make the function private, as this might 
cause confusion. ...?

Rainer

On Wed, 6 Sep 2006, Rainer Machne wrote:

> On Tue, 5 Sep 2006, W Eryk Wolski wrote:
>
>> Hi,
>>
>> Can we move the function
>> static int CvodeSettings_setTimeSeries(cvodeSettings_t *set, double
>> *timeseries, int PrintStep);
>>
>> to the API interface please? If one wants to set a whole time series
>> it is much more straightforward to do this using this function than
>> using:
>>
>> SBML_ODESOLVER_API int CvodeSettings_setTimeStep(cvodeSettings_t *,
>> int, double);
>> Especially that in case of this function it is not clear how to
>> specify the length of the time series to set first.
>>
>>
>> All the best.
>> Eryk
>
> Hi Eryk,
>
> Your point is good, but I remember that there was a reason to make this
> function "static/private". Unfortunately, I currently don't remember what
> the reason was ...
>
> It might either
> a) cause conflicts with the indefinitely setting or
> b) cause potential problems when a user sets a time series with starting
> values other then 0.
>
> However b seems to be avoided anyways because it is set to 0 and the
> first value of the passed time series is ignored.
>
> So I just added set->Indefinitely == 0; to be safe, and made this function
> part of the API.
>
> Or are there any concerns? Can anyone think of another reason to have this
> function private?
> Is it un-safe to have a function where two values must correspond to each
> other (PrintStep is the size of the array timeseries)?
>
> James, would you also want to move CvodeSettings_setAdjTimeSeries to the
> API?
>
> If no objections are brought up, I can submit these changes to CVS.
>
> Rainer
>
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> sbmlsolver-devel mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>

Re: [SOSlib-devel] Request for additional function in api interface.

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

On Tue, 5 Sep 2006, W Eryk Wolski wrote:

> Hi,
>
> Can we move the function
> static int CvodeSettings_setTimeSeries(cvodeSettings_t *set, double
> *timeseries, int PrintStep);
>
> to the API interface please? If one wants to set a whole time series
> it is much more straightforward to do this using this function than
> using:
>
> SBML_ODESOLVER_API int CvodeSettings_setTimeStep(cvodeSettings_t *,
> int, double);
> Especially that in case of this function it is not clear how to
> specify the length of the time series to set first.
>
>
> All the best.
> Eryk

Hi Eryk,

Your point is good, but I remember that there was a reason to make this 
function "static/private". Unfortunately, I currently don't remember what 
the reason was ...

It might either
a) cause conflicts with the indefinitely setting or
b) cause potential problems when a user sets a time series with starting 
values other then 0.

However b seems to be avoided anyways because it is set to 0 and the 
first value of the passed time series is ignored.

So I just added set->Indefinitely == 0; to be safe, and made this function 
part of the API.

Or are there any concerns? Can anyone think of another reason to have this 
function private?
Is it un-safe to have a function where two values must correspond to each 
other (PrintStep is the size of the array timeseries)?

James, would you also want to move CvodeSettings_setAdjTimeSeries to the 
API?

If no objections are brought up, I can submit these changes to CVS.

Rainer

[SOSlib-devel] Request for additional function in api interface.

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

Hi,

Can we move the function
static int CvodeSettings_setTimeSeries(cvodeSettings_t *set, double
*timeseries, int PrintStep);

to the API interface please? If one wants to set a whole time series
it is much more straightforward to do this using this function than
using:

 SBML_ODESOLVER_API int CvodeSettings_setTimeStep(cvodeSettings_t *,
int, double);
Especially that in case of this function it is not clear how to
specify the length of the time series to set first.


All the best.
Eryk

Re: [SOSlib-devel] comments on SBML L2 V2

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

Hi Michael,

This email also goes to the SOSlib developers' email list.

On Mon, 4 Sep 2006, Michael Hucka wrote:

> Andrew recently wrote the following to me in a separate
> message about the L2v2 draft specification:
>
>  afinney> the Example of the translation from
>  afinney> multicompartment models to odes:
>  afinney>
>  afinney> This model is correct as it stands but this type
>  afinney> of translation doesn't work when the compartment
>  afinney> volume varies i.e. is defined by an ODE.  In that
>  afinney> type of system the species odes need to be in
>  afinney> substance/time units.  The species concentrations
>  afinney> can then be computed by simple 'rules' applied to
>  afinney> intermediate species variables in substance
>  afinney> units.  The SOSlib team ran into this issue a
>  afinney> month or 2 ago.  I can't explain the math but we
>  afinney> could probably get them to explain this if you
>  afinney> want real proof.
>  afinney>
>  afinney> Perhaps we can have a variable compartment model
>  afinney> translated into Odes in addition to the existing
>  afinney> model
>  afinney>
>  afinney> either way there needs to some text describing
>  afinney> the limitations of the approach that's used in
>  afinney> the current text.
>
> I think the model in question in the examples section was
> contributed by Nicolas.  I'm afraid I'll run out of time
> to make all the remaining changes to the spec, so could I
> ask for people's help in doing as Andrew suggests above?

The example in section 5.6 has a variable compartment V1:
http://sbml.org/specifications/sbml-level-2/version-1/html/sbml-level-2.html#SECTION00056000000000000000

So I think the given translation to ODEs is wrong in the current state!! 
Or am I wrong? This topic confused me back then. Maybe Stefan or Luki can 
check section 5.6 and the following short explanation:

1) First the constant K3 (and all other Ks) is already corrected for some 
initial volume to convert the kinetic law to substance/time.

K3 = K3original * V1(0)
where K3original was in units [1/time] and K3 is in [volume/time], so 
K3*S3, with S3 as a concentration [substance/volume], yields the required 
[substance/time].

So K3 is actually a volume-dependent variable!!
The equation should rather have an explicit volume term, i.e.

K3original * V1 * S1

The volume corrections in kinetic laws should in general be done 
explicitly and it might be a good thing to note this in the specs 
compartment section.

2) Second the last ODE dS3/dt is wrong. A correct math would require a 
d[S3]/dV term to account for the influence of volume change on the 
concentration.

Imagine an initial concentration of 1 for S3(0) and a Volume V1 that has 
doubled at time t, V1(t) = 2 * V1(0). The ODE given would just add the 
changes by reactions but not changes to this initial condition by the 
volume change which at time t would only be 0.5. A term dS3/dV would 
account for this.

Fortunately there was an easier solution which Andrew mentioned above and 
which is outlined shortly at 
http://www.tbi.univie.ac.at/wiki/index.php/SOSlibDevel#Variable_Compartment_Sizes

1) write ODEs in substance/time, i.e. don't divide by the compartment, the 
left hand side of the ODEs are dXamount/dt rather then dX/dt; the ODE 
solver will the calculate Xamount.
2) write assignment rules for species concentrations which are required at 
the right hand side of ODEs:
X = Xamount / Volume.

Let me know if we can contribute something specific to the new draft.

Rainer



>
> The possible outcomes are as follows, in decreasing value of
> goodness:
>
> 1. Someone writes a 2nd model (and corresponding
>   explanation) that handles the variable volume case.  We
>   add this model as an additional example in the examples
>   section, and also modifies the description of the
>   existing constant-volume model to explain it's a common
>   but special case, it's limited, doesn't handle varying
>   volumes, etc.
>
> 2. Someone modifies the existing model to make it handle
>   varying volumes, and we leave just the one model, because
>   it's the most general case.
>
> 3. We decide we don't have time to create a new general
>   example, and instead only edit the existing
>   constant-volume model to explain its limitations.
>
> 4. I add a sentence to the existing constant-volume model
>   example description mentioning that it's only for
>   constant volumes "and this does not properly handle the
>   more general case".
>
> Let me know if anyone can do something.
>
> MH
>

Re: [SOSlib-devel] SBML meeting (fwd)

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

Hi James and Stefan,

you asked about a possible short SOSlib presentation at the SBML meeting.
Below you find some suggestions by Michael Hucka about topics potentially 
interesting for the audience there.

The first point is about implemented features. So maybe we can make a few 
nice slides about forward sensitivity and the adjoint stuff, i.e. 
sensitivity gradients. Maybe we can show how easy it is to do an 
iteration towards a local minimum? Could we use some of your (James) work 
on cell cycle or circadian models for this?

Ok, at this point, I decided to Cc this email to the SOSlib development 
list. Do people have suggestions what could be interesting for other 
users?

Akira, please see Michael's last point. What could we say about this 
point?

And Xtof, maybe we should warm up our idea about the developer and 
user survey and feedback request for the second point in Michael's list:
most used existing functionalities and most wanted non-existing features, 
to make a priority queue not only for exact event detection but also 
for our TODO list, see
http://www.tbi.univie.ac.at/wiki/index.php/SOSlibDevel

Rainer



---------- Forwarded message ----------
Date: Fri, 1 Sep 2006 13:31:16 -0700
From: Michael Hucka <mh...@ca...>
To: Rainer Machne <ra...@tb...>
Cc: Andrew Finney <af...@ph...>
Subject: Re: SBML meeting

   raim> Would people be interested in a short presentation
   raim> on SOSlib?  If yes, what parts of it?

Hi Rainer,

Here are just a few ideas:

- A quick survey of the features implemented, solver used,
   the fact that there is a web service, etc.

- Discuss the limitations, e.g. with respect to handling
   events, delays (and also ideas for what needs to be done
   to overcome the limitations, if someone wanted to make a
   contribution to SOSlib's development)

- Experiences with embedding SOSlib in other applications
   such as CellDesigner

MH

[SOSlib-devel] SOLVED: Problem with senstivities

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

Hi Eryk,

oh, how i love bugfixing :-) especially when meandering around to places 
far away from a very stupid and simple bug.

When creating the sensitivity solver structures the initial sensitivities 
yS where initialized after both CVodeSensMalloc or the alternative used in 
subsequent loops, CVodeSensReInit. yS is passed to both functions.

While in the first case this didn't cause problems, for reinitiation CVode 
overruled the initialization with its internal values upon the first call 
of CVode in the _cvodeOneStep function.

During meandering around I also realized that the CVodeSens structure 
requires its own free, CVodeSensFree, which was missing so far and caused 
the error, when I experimentally destroyed and re-created the sens. 
structures instead of ReInitializing. The missing free also is responsible 
for earlier observations of significant memory leaks of the sensitivity 
tools in SOSlib. These have also gone, at least during some initial test.

Eryk, can update from CVS and try your tool? I am confident that the 
sensitivities now should be the same for all iterations. Here it works.

Also, if you find the time, you could report this bug to the sourceforge 
bug list, as you found it. Ifit works for you, I can then close the bug 
with explanations :)

cheers
Rainer



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

> I wish you wer right. Of course I have tested this by setting exactly
> the same parameters values again and again. And the reported behaviour
> applies also in this case. That is, the sensitvities are changing and
> their magnitude is increasing with each new evaluation of the model
> independently of the parameters set.
>
> Did you tried reconstructing the loop yourself and testing it? I am
> quite curious what is your observation.
>
> cheers
>
>
>
>
> On 8/28/06, Rainer Machne <ra...@tb...> wrote:
>> Hi Eryk,
>>
>>
>> you wrote:
>>
>>> the loop includes:
>>> {
>>> change of the parameters
>>
>> ... and ...
>>
>>> What I observe and call a problem is that every new simulator run in
>>> the loop generates increasing sensitivity values for the same
>>> parameter values and model.
>>
>
>
>> For the first statement `change of the parameters' it would be obvious,
>> that sensitivities change, I guess the sensitivities can also change their
>> sign, e.g. if during the parameter change you cross a bifurcation point.
>>
>> This can of course also happen for parameters that you have not changed!
>> I.e. you change parameter A across a bifurcation point. Then the behaviour
>> of the system completely changes. Then of course also the sensitivities to
>> unchanged parameters change. They can even change their sign.
>>
>> Do you also observe the change of sensitivities if you DO NOT change the
>> parameters between the runs?
>>
>> Rainer
>>
>>
> Rainer, this might be obvious, but imagine
>
>
>
>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Tue, 15 Aug 2006, W Eryk Wolski wrote:
>>
>>> Hi,
>>>
>>> I am running the solver in a loop.
>>>
>>> the loop includes:
>>> {
>>> change of the parameters
>>> running the solver
>>> and a call to IntegratorInstance_reset(integratorInstance);
>>> }
>>>
>>> What I observe and call a problem is that every new simulator run in
>>> the loop generates increasing sensitivity values for the same
>>> parameter values and model.
>>>
>>> The following output are the date stored in:
>>>
>>> integratorInstance->data->sensitivity
>>> entries
>>> integratorInstance->data->nsens, integratorInstance->data->neq
>>>
>>> first iteration
>>>
>>> parameters:  par[0] 2.000000  par[1] 8.000000  par[2] 10.000000
>>> par[3] 0.100000  par[4] 2.000000
>>>
>>> 24.33599      -12.44311       -1.60336        0.28326 26.31235        -0.12182        0.00000 0.00000
>>> -24.33599     12.44311        1.60336 -0.28326        -26.31235       0.12182 0.00000 11.93225
>>> 11.93225      -4.09705        -0.54112        0.08923 8.68924 -0.04727        0.00000 -7.76276
>>> -7.76276      2.05021 0.27103 -0.04458        -4.34843        0.02380 0.00000 -4.16949
>>> -4.16949      2.04684 0.27009 -0.04465        -4.34081        0.02346 0.00000 -0.26712
>>> -0.26712      -0.45221        -0.06041        0.00965 0.95925 -0.00565        0.00000 -1.57271
>>>
>>>
>>> while the 10 iteration:
>>>
>>> -1394.82594   399.44848       59.25448        -19.98846       -2225.46440     3.11907 0.00000 0.00000
>>> 1394.82594    -399.44848      -59.25448       19.98846        2225.46440      -3.11907        0.00000 -21877.33372
>>> -21877.33372  6547.28853      971.83061       -324.87728      -36996.03248    52.60350        0.00000 -2206.49496
>>> -2206.49496   666.20014       98.97768        -33.06429       -3791.30589     5.39430 0.00000 24083.82868
>>> 24083.82868   -7213.48867     -1070.80829     357.94157       40787.33837     -57.99780       0.00000 -21953.82949
>>> -21953.82949  6578.30322      976.54971       -326.41598      -37205.87555    52.90915        0.00000 12235.00898
>>>
>>>
>>>
>>> I hope that the problem statement is clear but I am happy to answer
>>> more questions.
>>> I am looking forward to suggestions.
>>>
>>> Eryk
>>>
>>> -------------------------------------------------------------------------
>>> Using Tomcat but need to do more? Need to support web services, security?
>>> Get stuff done quickly with pre-integrated technology to make your job easier
>>> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>>> _______________________________________________
>>> sbmlsolver-devel mailing list
>>> sbm...@li...
>>> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>>>
>>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> sbmlsolver-devel mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>

Re: [SOSlib-devel] sensitivity in iterative runs (fwd)

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

A short update:

Ok, I have found one error in SOSlib, which however wasn't the cause for 
the problem Eryk reported.

We never did any CVodeSensFree. I must have overlooked the need for this.
However, this should not be called in the current situation anyways, 
because the dimension of sensitivity analysis (data-> and solver->nsens) 
stays the same between iterations, i.e. for s.a. for ALL parameterst 
nconst. In this case CVodeSensReInit can be used. And this still doesn't 
work!


However, if I free the sens structures between iterations (i.e. by _reset 
function), we get better results but still strange although 
small deviations between the runs:

The first 4 sensitivities in MAPK.xml at time 3:

1st run:
  0.0323545 -0.0323545 0.00119977 -0.000683849
2nd run:
  0.0322987 -0.0330522 0.0101251 -0.00341986 
3rd run:
  0.0322956 -0.0330456 0.0101108 -0.00343846

...
10th run:
  0.0322956 -0.0330456 0.0101108 -0.00343846

Note that the sensitivities change a bit during the first three runs, and 
then stay the same until the 10th run.

Very strange !!??

The initial problem, that the ReInit (as used by the current CVS 
version) produces errors is still there, however.

Radu Serban has answered on the sundials list and cannot reproduce the 
problem.

One good thing:
we got rid of memory leaks in sens.analysis because CVodeSensFree is now 
called in the final freeing of solver structures :)


Rainer





On Tue, 29 Aug 2006, Rainer Machne wrote:

>
> I have sent below email to the sundials list and forgot to cc it to our
> list. I will forward the responses.
>
> r
>
> ---------- Forwarded message ----------
> Date: Tue, 29 Aug 2006 17:20:25 +0200 (CEST)
> From: Rainer Machne <ra...@me...>
> To: sun...@ll...
> Subject: sensitivity in iterative runs
>
> Dear Sundials users/developers,
>
>
> In our software we use the ReInit functions of both CVode and CVodeSens
> (version 2.1.1) to run arbitrary numbers of integration runs.
>
> We get however different sensitivities s(x(t)) with each run, even if we don't
> change any parameters or initial conditions, i.e. with exactly the same model,
> for which CVode also returns the same results x(t).
>
> I have tried different combinations of using either ReInit or a completely new
> creation of cvode solver structures.
>
>  Both,
> a) freeing and recreating the sensitivity structures with
> N_VNewVectorArray_Serial and CVodeSensMalloc or
> b) reinitializing these structures with CVodeSensReInit
> produce wrong results. The results are different from each other, though.
>
> In the CVodeSensReInit case, the results look somehow `more correct':
> e.g. two variables with exactly opposite sensitivities (x/-) to one parameter
> stay this way for iterative runs, although with different values.
>
> Here some results for the same output time (3.0) and different iterations,
> sensitivities of two variables to the same parameter:
>
> both cases:
>  1st run:   0.0323545 -0.0323545
>
> a) destroying and recreating CVodeSens structures:
>  2nd run:   0.0386666 -2.81625
> 10th run:   0.0228166 -14.0761
>
> b) using CVodeSensReInit:
>  2nd run:   0.0640767 -0.0640767
> 10th run:   0.294778 -0.294778
>
> The results x(t) are the same for all cases, i.e. 87.2221 and 12.7779.
> The parameter towards which sensitivity is tested has the value 10.
>
> Note, that the symmetry is kept when using ReInit, while one sensitivity is
> growing much bigger for the destroy/create case.
>
>
> The only way to get consistent results is to destroy and recreate the whole
> CVode solver structures with CVodeCreate.
>
> Could this be a bug in SUNDIALS or do you see any hints what we might do wrong
> in our software from above results??
> If it's a bug in Sundials, I guess it must be some structure in the CVode
> forward solver that is important for CVodeSens but created independently of the
> latter. ??
>
> Sorry, if this has been brought up and discussed before, I didn't find the
> email archives online.
>
> Thanks,
> Rainer Machne
>
>
> Theoretical Biochemistry Group
> Department for Theoretical Chemistry
> University of Vienna
> Austria/Europe
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> sbmlsolver-devel mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>

[SOSlib-devel] sensitivity in iterative runs (fwd)

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

I have sent below email to the sundials list and forgot to cc it to our 
list. I will forward the responses.

r

---------- Forwarded message ----------
Date: Tue, 29 Aug 2006 17:20:25 +0200 (CEST)
From: Rainer Machne <ra...@me...>
To: sun...@ll...
Subject: sensitivity in iterative runs

Dear Sundials users/developers,


In our software we use the ReInit functions of both CVode and CVodeSens
(version 2.1.1) to run arbitrary numbers of integration runs.

We get however different sensitivities s(x(t)) with each run, even if we don't 
change any parameters or initial conditions, i.e. with exactly the same model, 
for which CVode also returns the same results x(t).

I have tried different combinations of using either ReInit or a completely new 
creation of cvode solver structures.

  Both,
a) freeing and recreating the sensitivity structures with 
N_VNewVectorArray_Serial and CVodeSensMalloc or
b) reinitializing these structures with CVodeSensReInit
produce wrong results. The results are different from each other, though.

In the CVodeSensReInit case, the results look somehow `more correct':
e.g. two variables with exactly opposite sensitivities (x/-) to one parameter 
stay this way for iterative runs, although with different values.

Here some results for the same output time (3.0) and different iterations, 
sensitivities of two variables to the same parameter:

both cases:
  1st run:   0.0323545 -0.0323545

a) destroying and recreating CVodeSens structures:
  2nd run:   0.0386666 -2.81625
10th run:   0.0228166 -14.0761

b) using CVodeSensReInit:
  2nd run:   0.0640767 -0.0640767
10th run:   0.294778 -0.294778

The results x(t) are the same for all cases, i.e. 87.2221 and 12.7779.
The parameter towards which sensitivity is tested has the value 10.

Note, that the symmetry is kept when using ReInit, while one sensitivity is 
growing much bigger for the destroy/create case.


The only way to get consistent results is to destroy and recreate the whole 
CVode solver structures with CVodeCreate.

Could this be a bug in SUNDIALS or do you see any hints what we might do wrong 
in our software from above results??
If it's a bug in Sundials, I guess it must be some structure in the CVode 
forward solver that is important for CVodeSens but created independently of the 
latter. ??

Sorry, if this has been brought up and discussed before, I didn't find the 
email archives online.

Thanks,
Rainer Machne


Theoretical Biochemistry Group
Department for Theoretical Chemistry
University of Vienna
Austria/Europe

Re: [SOSlib-devel] Problem with senstivities

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

Hi Eryk,

I have played around a bit and am quite sure that we can blame it on 
Sundials.

In the current version we don't free the cvode internal 
sensitivity vectors yS, but only use the cvode reinit function. This 
should be Ok - this what the ReInit should be for - but anyways I tried 
with freeing instead.

I get different but still not correct results!

When resetting these internal yS values to 0, they are zero right after 
that and right until calling CVodeGetSens in 
IntegratorInstance_getForwardSens for the first time. But already there 
they already have the strange values changing with each iteration.

It doesn't matter whether Sens ReInit or Sens is freed and a completely 
new  forward sensitivity structure is created: both cases yield 
wrong results.

Also, I remember having tested iteration of sensitivity before the 
official 1.6.0 release, and it worked fine. I started to suspect the 
normal CVodeReInit which wasn't there in 1.6.0. We always completely freed 
and initialized the whole solver in this version.

Thus I tested the loop with 1.6.0. And it works fine!

Ok, if above was not clear:

I strongly suspect that we have found a bug in CVODES!!
When doing a CVodeReInit, some internal structure used for sensitivity 
analysis seems not to be correctly freed and used again for the next 
runs, no matter whether the the CVode sensitivity structures have been 
"ReInit"ialized or completely freed and created again. Both procedures 
yield wrong results. The bug must somewhere between in CVodeReInit and
CVodeSensReInit

I have listed below older bugs, that should be fixed in the 2.1.1 version 
of SUNDIALS, but they point to the still buggy nature of SUNDIALS 
sensitivity tools.

We should probably search their email list whether this has been discussed 
already or is fixed in a current version. Or whether we still might do 
something wrong.

That's it so far.

Rainer



What's new in v2.1.1?
fixed bug in sensitivity computations on an order increase (when using 
BDF).

What's new in v2.1.0?
fixed bug in adjustment of sensitivity Nordsieck history array on an order 
decrease (when using BDF).


On Tue, 29 Aug 2006, Rainer Machne wrote:

>
> I have just tried such a loop (starting from
> examples/sensitivity.c) without changing any parameters and I also get
> these strange results!
>
> Interestingly, some symmetric relations are still there.
>
> E.g. in the example model MAPK.xml the sensitivities of species MKKK and
> MKKK_p to parameter Ki have exactly opposite (i.e. +/-) sensitivities:
>
> #time  MKKK MKKK_P
>
> first run:
> 300  0.901181 -0.901181
>
> second run:
> 300  -0.49678 0.49678
>
> third run:
> 300  1.84961 -1.84961
>
> ...
> ninth run:
> 300  36.1583 -36.1583
>
> tenth run:
> 300  -60.514 60.514
>
> Interestingly, the sensitivities change their sign with each run.
>
> Rainer
>
> On Tue, 29 Aug 2006, W Eryk Wolski wrote:
>
>> I wish you wer right. Of course I have tested this by setting exactly
>> the same parameters values again and again. And the reported behaviour
>> applies also in this case. That is, the sensitvities are changing and
>> their magnitude is increasing with each new evaluation of the model
>> independently of the parameters set.
>>
>> Did you tried reconstructing the loop yourself and testing it? I am
>> quite curious what is your observation.
>>
>
>
>
>> cheers
>>
>>
>>
>>
>> On 8/28/06, Rainer Machne <ra...@tb...> wrote:
>>> Hi Eryk,
>>>
>>>
>>> you wrote:
>>>
>>>> the loop includes:
>>>> {
>>>> change of the parameters
>>>
>>> ... and ...
>>>
>>>> What I observe and call a problem is that every new simulator run in
>>>> the loop generates increasing sensitivity values for the same
>>>> parameter values and model.
>>>
>>
>>
>>> For the first statement `change of the parameters' it would be obvious,
>>> that sensitivities change, I guess the sensitivities can also change their
>>> sign, e.g. if during the parameter change you cross a bifurcation point.
>>>
>>> This can of course also happen for parameters that you have not changed!
>>> I.e. you change parameter A across a bifurcation point. Then the behaviour
>>> of the system completely changes. Then of course also the sensitivities to
>>> unchanged parameters change. They can even change their sign.
>>>
>>> Do you also observe the change of sensitivities if you DO NOT change the
>>> parameters between the runs?
>>>
>>> Rainer
>>>
>>>
>> Rainer, this might be obvious, but imagine
>>
>>
>>
>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Tue, 15 Aug 2006, W Eryk Wolski wrote:
>>>
>>>> Hi,
>>>>
>>>> I am running the solver in a loop.
>>>>
>>>> the loop includes:
>>>> {
>>>> change of the parameters
>>>> running the solver
>>>> and a call to IntegratorInstance_reset(integratorInstance);
>>>> }
>>>>
>>>> What I observe and call a problem is that every new simulator run in
>>>> the loop generates increasing sensitivity values for the same
>>>> parameter values and model.
>>>>
>>>> The following output are the date stored in:
>>>>
>>>> integratorInstance->data->sensitivity
>>>> entries
>>>> integratorInstance->data->nsens, integratorInstance->data->neq
>>>>
>>>> first iteration
>>>>
>>>> parameters:  par[0] 2.000000  par[1] 8.000000  par[2] 10.000000
>>>> par[3] 0.100000  par[4] 2.000000
>>>>
>>>> 24.33599      -12.44311       -1.60336        0.28326 26.31235        -0.12182        0.00000 0.00000
>>>> -24.33599     12.44311        1.60336 -0.28326        -26.31235       0.12182 0.00000 11.93225
>>>> 11.93225      -4.09705        -0.54112        0.08923 8.68924 -0.04727        0.00000 -7.76276
>>>> -7.76276      2.05021 0.27103 -0.04458        -4.34843        0.02380 0.00000 -4.16949
>>>> -4.16949      2.04684 0.27009 -0.04465        -4.34081        0.02346 0.00000 -0.26712
>>>> -0.26712      -0.45221        -0.06041        0.00965 0.95925 -0.00565        0.00000 -1.57271
>>>>
>>>>
>>>> while the 10 iteration:
>>>>
>>>> -1394.82594   399.44848       59.25448        -19.98846       -2225.46440     3.11907 0.00000 0.00000
>>>> 1394.82594    -399.44848      -59.25448       19.98846        2225.46440      -3.11907        0.00000 -21877.33372
>>>> -21877.33372  6547.28853      971.83061       -324.87728      -36996.03248    52.60350        0.00000 -2206.49496
>>>> -2206.49496   666.20014       98.97768        -33.06429       -3791.30589     5.39430 0.00000 24083.82868
>>>> 24083.82868   -7213.48867     -1070.80829     357.94157       40787.33837     -57.99780       0.00000 -21953.82949
>>>> -21953.82949  6578.30322      976.54971       -326.41598      -37205.87555    52.90915        0.00000 12235.00898
>>>>
>>>>
>>>>
>>>> I hope that the problem statement is clear but I am happy to answer
>>>> more questions.
>>>> I am looking forward to suggestions.
>>>>
>>>> Eryk
>>>>
>>>> -------------------------------------------------------------------------
>>>> Using Tomcat but need to do more? Need to support web services, security?
>>>> Get stuff done quickly with pre-integrated technology to make your job easier
>>>> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>>>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>>>> _______________________________________________
>>>> sbmlsolver-devel mailing list
>>>> sbm...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>>>>
>>>
>>
>> -------------------------------------------------------------------------
>> Using Tomcat but need to do more? Need to support web services, security?
>> Get stuff done quickly with pre-integrated technology to make your job easier
>> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>> _______________________________________________
>> sbmlsolver-devel mailing list
>> sbm...@li...
>> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> sbmlsolver-devel mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>

Re: [SOSlib-devel] Problem with senstivities

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

I have just tried such a loop (starting from 
examples/sensitivity.c) without changing any parameters and I also get 
these strange results!

Interestingly, some symmetric relations are still there.

E.g. in the example model MAPK.xml the sensitivities of species MKKK and 
MKKK_p to parameter Ki have exactly opposite (i.e. +/-) sensitivities:

#time  MKKK MKKK_P

first run:
300  0.901181 -0.901181

second run:
300  -0.49678 0.49678

third run:
300  1.84961 -1.84961

...
ninth run:
300  36.1583 -36.1583

tenth run:
300  -60.514 60.514

Interestingly, the sensitivities change their sign with each run.

Rainer

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

> I wish you wer right. Of course I have tested this by setting exactly
> the same parameters values again and again. And the reported behaviour
> applies also in this case. That is, the sensitvities are changing and
> their magnitude is increasing with each new evaluation of the model
> independently of the parameters set.
>
> Did you tried reconstructing the loop yourself and testing it? I am
> quite curious what is your observation.
>



> cheers
>
>
>
>
> On 8/28/06, Rainer Machne <ra...@tb...> wrote:
>> Hi Eryk,
>>
>>
>> you wrote:
>>
>>> the loop includes:
>>> {
>>> change of the parameters
>>
>> ... and ...
>>
>>> What I observe and call a problem is that every new simulator run in
>>> the loop generates increasing sensitivity values for the same
>>> parameter values and model.
>>
>
>
>> For the first statement `change of the parameters' it would be obvious,
>> that sensitivities change, I guess the sensitivities can also change their
>> sign, e.g. if during the parameter change you cross a bifurcation point.
>>
>> This can of course also happen for parameters that you have not changed!
>> I.e. you change parameter A across a bifurcation point. Then the behaviour
>> of the system completely changes. Then of course also the sensitivities to
>> unchanged parameters change. They can even change their sign.
>>
>> Do you also observe the change of sensitivities if you DO NOT change the
>> parameters between the runs?
>>
>> Rainer
>>
>>
> Rainer, this might be obvious, but imagine
>
>
>
>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Tue, 15 Aug 2006, W Eryk Wolski wrote:
>>
>>> Hi,
>>>
>>> I am running the solver in a loop.
>>>
>>> the loop includes:
>>> {
>>> change of the parameters
>>> running the solver
>>> and a call to IntegratorInstance_reset(integratorInstance);
>>> }
>>>
>>> What I observe and call a problem is that every new simulator run in
>>> the loop generates increasing sensitivity values for the same
>>> parameter values and model.
>>>
>>> The following output are the date stored in:
>>>
>>> integratorInstance->data->sensitivity
>>> entries
>>> integratorInstance->data->nsens, integratorInstance->data->neq
>>>
>>> first iteration
>>>
>>> parameters:  par[0] 2.000000  par[1] 8.000000  par[2] 10.000000
>>> par[3] 0.100000  par[4] 2.000000
>>>
>>> 24.33599      -12.44311       -1.60336        0.28326 26.31235        -0.12182        0.00000 0.00000
>>> -24.33599     12.44311        1.60336 -0.28326        -26.31235       0.12182 0.00000 11.93225
>>> 11.93225      -4.09705        -0.54112        0.08923 8.68924 -0.04727        0.00000 -7.76276
>>> -7.76276      2.05021 0.27103 -0.04458        -4.34843        0.02380 0.00000 -4.16949
>>> -4.16949      2.04684 0.27009 -0.04465        -4.34081        0.02346 0.00000 -0.26712
>>> -0.26712      -0.45221        -0.06041        0.00965 0.95925 -0.00565        0.00000 -1.57271
>>>
>>>
>>> while the 10 iteration:
>>>
>>> -1394.82594   399.44848       59.25448        -19.98846       -2225.46440     3.11907 0.00000 0.00000
>>> 1394.82594    -399.44848      -59.25448       19.98846        2225.46440      -3.11907        0.00000 -21877.33372
>>> -21877.33372  6547.28853      971.83061       -324.87728      -36996.03248    52.60350        0.00000 -2206.49496
>>> -2206.49496   666.20014       98.97768        -33.06429       -3791.30589     5.39430 0.00000 24083.82868
>>> 24083.82868   -7213.48867     -1070.80829     357.94157       40787.33837     -57.99780       0.00000 -21953.82949
>>> -21953.82949  6578.30322      976.54971       -326.41598      -37205.87555    52.90915        0.00000 12235.00898
>>>
>>>
>>>
>>> I hope that the problem statement is clear but I am happy to answer
>>> more questions.
>>> I am looking forward to suggestions.
>>>
>>> Eryk
>>>
>>> -------------------------------------------------------------------------
>>> Using Tomcat but need to do more? Need to support web services, security?
>>> Get stuff done quickly with pre-integrated technology to make your job easier
>>> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>>> _______________________________________________
>>> sbmlsolver-devel mailing list
>>> sbm...@li...
>>> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>>>
>>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> sbmlsolver-devel mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>

Re: [SOSlib-devel] Problem with senstivities

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

I wish you wer right. Of course I have tested this by setting exactly
the same parameters values again and again. And the reported behaviour
applies also in this case. That is, the sensitvities are changing and
their magnitude is increasing with each new evaluation of the model
independently of the parameters set.

 Did you tried reconstructing the loop yourself and testing it? I am
quite curious what is your observation.

cheers




On 8/28/06, Rainer Machne <ra...@tb...> wrote:
> Hi Eryk,
>
>
> you wrote:
>
> > the loop includes:
> > {
> > change of the parameters
>
> ... and ...
>
> > What I observe and call a problem is that every new simulator run in
> > the loop generates increasing sensitivity values for the same
> > parameter values and model.
>


> For the first statement `change of the parameters' it would be obvious,
> that sensitivities change, I guess the sensitivities can also change their
> sign, e.g. if during the parameter change you cross a bifurcation point.
>
> This can of course also happen for parameters that you have not changed!
> I.e. you change parameter A across a bifurcation point. Then the behaviour
> of the system completely changes. Then of course also the sensitivities to
> unchanged parameters change. They can even change their sign.
>
> Do you also observe the change of sensitivities if you DO NOT change the
> parameters between the runs?
>
> Rainer
>
>
Rainer, this might be obvious, but imagine




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