RE: [SOSlib-devel] simple event handling corrected[Scanned]

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

Rainer

I think a simpler API is easier to maintain.

yours Andrew=20

> -----Original Message-----
> From: Rainer Machne [mailto:ra...@tb...]=20
> Sent: 19 April 2006 15:35
> To: Andrew Finney
> Cc: SOSlib Development
> Subject: RE: [SOSlib-devel] simple event handling corrected[Scanned]
>=20
>=20
> On Wed, 19 Apr 2006, Andrew Finney wrote:
>=20
> >
> >> * remove redundant function II_checkTrigger or alternatively
> >> * provide this function as API -- maybe without the event=20
> execution ??
> >>
> >>
> >
> > if it aint called get rid of it
>=20
> Ok, I agree.
>=20
> I just thought that, if the function
>=20
> IntegratorInstance_integrateOneStepWithoutEventProcessing
>=20
> is part of the API, people might still be interested in a=20
> simple external checking for number of events.
>=20
> Besides the confusion about it's declaration, the question=20
> whether you wanted this function part of the API was=20
> regarding this function.
>=20
> What use do you imagine for this function? Is it just for testing?
>=20
>=20
>=20
>=20
> >> * decide on whether or not to have API functions for solverOneStep=20
> >> (for each solver, no ODES, CVODES, IDA, etc.) or if this should be=20
> >> handled inside the library and integrateOneStep will be=20
> the only API=20
> >> one step function
> >>
> >
> > my preference is to have only one API one step function
>=20
> Ok, I guess the few if statments in the integrateOneStep will=20
> not be really a performance drawback.
>=20
> Initially, I made the cvodeOneStep and simpleOneStep=20
> functions public (part of the API) to enable the most direct=20
> use of a specific solver for applications that know what type=20
> of model they have.
>=20
> It would be easy but is not possible anymore with the
>=20
>  	engine->processEvents
>=20
> option, set within above discussed function, unless we add
>=20
> cvodeOneStepWithoutEventProcessing
> simpleOneStepWithoutEventProcessing
>=20
> and eventually
>=20
> idaOneStepWithoutEventProcessing
>=20
> and others.
>=20
> The integratorOneStep was thought to be a simple wrapper for=20
> applications that don't know there model types.
>=20
> Rainer
>=20
>=20
>=20
>=20
> >> -----Original Message-----
> >> From: sbm...@li...
> >> [mailto:sbm...@li...] On Behalf Of=20
> >> Rainer Machne
> >> Sent: 19 April 2006 14:56
> >> To: SOSlib Development
> >> Subject: [SOSlib-devel] simple event handling corrected[Scanned]
> >>
> >> Hi All
> >>
> >> Just wanted to let you know, that I have submitted a
> >> (hopefully) corrected version of the simple event handling.
> >>
> >> TODOs found:
> >>
> >> * clean up the use of the SBML_ODESOLVER_API tag (part of C++ API=20
> >> todo)
> >>
> >> * decide wheter private functions should be declared at=20
> the header of=20
> >> the c file
> >>
> >> * remove redundant function II_checkTrigger or alternatively
> >> * provide this function as API -- maybe without the event=20
> execution ??
> >>
> >>
> >> * decide on whether or not to have API functions for solverOneStep=20
> >> (for each solver, no ODES, CVODES, IDA, etc.) or if this should be=20
> >> handled inside the library and integrateOneStep will be=20
> the only API=20
> >> one step function
> >>
> >> Rainer
> >>
> >>
> >>
> >>
> >> On Wed, 19 Apr 2006, Andrew Finney wrote:
> >>
> >>> Rainer
> >>>
> >>> IntegratorInstance_processEventsAndAssignments
> >>>
> >>> doesn't have a declaration: its not required as its not=20
> part of the=20
> >>> API the SBML_ODESOLVER_API qualification is redundant - I
> >> guess that
> >>> confused you That's my fault.  Remind me to update the=20
> dynalically=20
> >>> compiled version of this function.
> >>>
> >>> you're probably OK as far as CVS goes
> >>>
> >>> Andrew
> >>>
> >>>> -----Original Message-----
> >>>> From: Rainer Machne [mailto:ra...@tb...]
> >>>> Sent: 19 April 2006 14:35
> >>>> To: Andrew Finney
> >>>> Cc: SOSlib Development
> >>>> Subject: Re: [SOSlib-devel] RE: comment on proposed exact event=20
> >>>> implementation[Scanned]
> >>>>
> >>>>
> >>>> On Wed, 19 Apr 2006, Andrew Finney wrote:
> >>>>
> >>>>> Rainer
> >>>>>
> >>>>> strange
> >>>>>
> >>>>> I have the declaration at
> >>>>> SBML_odeSolver\src\sbmlsolver\integratorInstance.h line 143
> >>>>
> >>>> At line 143 I only have a declaration for=20
> >>>> IntegratorInstance_integrateOneStepWithoutEventProcessing
> >>>>
> >>>> but can't find a declaration for
> >>>> IntegratorInstance_processEventsAndAssignments
> >>>>
> >>>>>
> >>>>> my CVS is saying that I'm in sync
> >>>>>
> >>>>> what do you have?
> >>>>
> >>>> mine too. that's really strange. Maybe cvs update checks=20
> only for=20
> >>>> version numbers and there is a problem with that?
> >>>>
> >>>> I have v 1.27 2006/04/11 13:10:45 afinney
> >>>>
> >>>> Strangely, the only CVS has version 1.26 from 5 weeks ago, while=20
> >>>> other files there are more recent.
> >>>>
> >>>> Rainer
> >>>>
> >>>>>
> >>>>> yours Andrew
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Rainer Machne [mailto:ra...@tb...]
> >>>>>> Sent: 19 April 2006 12:42
> >>>>>> To: Andrew Finney
> >>>>>> Cc: SOSlib Development
> >>>>>> Subject: RE: comment on proposed exact event
> >>>> implementation[Scanned]
> >>>>>>
> >>>>>> Andrew
> >>>>>>
> >>>>>> I have correct the simple event detection, so that it
> >> doesn't set
> >>>>>> trigger flags to 0, if the trigger is actually still fired.
> >>>>>>
> >>>>>> Some questions regarding the new code:
> >>>>>>
> >>>>>> Now that enginge->processEvents is set either to 1 or to 0 in=20
> >>>>>> II_integrateOneStep and
> >> II_integrateOneStepWithoutEventProcessing,
> >>>>>> respectively, the functions
> >>>>>>
> >>>>>> II_simpleOneStep and II_cvodeOneStep
> >>>>>>
> >>>>>> shouldn't be public anymore.
> >>>>>>
> >>>>>> Before this new switch, they were public, so that
> >>>> applications which
> >>>>>> knew what type of solver is required (currently ODEs or no
> >>>> ODEs, but
> >>>>>> eventually also DAEs or even stochastic solvers) can use these=20
> >>>>>> `solver'OneStep functions directly.
> >>>>>>
> >>>>>> Should we remove these functions from the API or should we
> >>>> keep the
> >>>>>> possibility to use different solvers directly?
> >>>>>>
> >>>>>> In the second case we need to move the
> >>>> engine->processEvents setting
> >>>>>> to some other place!
> >>>>>>
> >>>>>> Also I didn't find a function declaration for=20
> >>>>>> II_integrateOneStepWithoutEventProcessing. I guess you
> >> wanted this
> >>>>>> function to be public, or did you just use it for testing?
> >>>>>>
> >>>>>>
> >>>>>> Rainer
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Wed, 19 Apr 2006, Andrew Finney wrote:
> >>>>>>
> >>>>>>> Rainer
> >>>>>>>
> >>>>>>> I guess you need to go ahead and modify the code.
> >>>>>>> Any performance hit is my problem.
> >>>>>>>
> >>>>>>> yours Andrew
> >>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: Rainer Machne [mailto:ra...@tb...]
> >>>>>>>> Sent: 19 April 2006 11:47
> >>>>>>>> To: Andrew Finney
> >>>>>>>> Subject: RE: comment on proposed exact event
> >>>>>> implementation[Scanned]
> >>>>>>>>
> >>>>>>>> Andrew
> >>>>>>>>
> >>>>>>>>> I'm more worried about the performance hit of
> >>>> evaluating the not
> >>>>>>>>> trigger expression.
> >>>>>>>>
> >>>>>>>> Ok, I still don't get what you mean.
> >>>>>>>>
> >>>>>>>> Do you mind, if I correct the current event handling -
> >>>> as outlined
> >>>>>>>> two emails below - and submit it, or do you think it would
> >>>>>> slow down
> >>>>>>>> your models?
> >>>>>>>>
> >>>>>>>> Rainer
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Wed, 12 Apr 2006, Andrew Finney wrote:
> >>>>>>>>
> >>>>>>>>> Rainer
> >>>>>>>>>
> >>>>>>>>> you're doing the right thing don't worry  :-)
> >>>>>>>>>
> >>>>>>>>>> -----Original Message-----
> >>>>>>>>>> From: Rainer Machne [mailto:ra...@tb...]
> >>>>>>>>>> Sent: 12 April 2006 17:53
> >>>>>>>>>> To: Andrew Finney
> >>>>>>>>>> Cc: Christoph Flamm
> >>>>>>>>>> Subject: RE: comment on proposed exact event
> >>>>>>>> implementation[Scanned]
> >>>>>>>>>>
> >>>>>>>>>> Andrew
> >>>>>>>>>>
> >>>>>>>>>> On Wed, 12 Apr 2006, Andrew Finney wrote:
> >>>>>>>>>>
> >>>>>>>>>>> Rainer
> >>>>>>>>>>>
> >>>>>>>>>>> Our model is based on simple Jarnac code.
> >>>>>>>>>>>
> >>>>>>>>>>> I'm more worried about the performance hit of
> >>>>>> evaluating the not
> >>>>>>>>>>> trigger expression.
> >>>>>>>>>>
> >>>>>>>>>> I don't really understand what you mean.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> You mean the additional evaluations when
> >>>>>>>>>>
> >>>>>>>>>>>>>   else
> >>>>>>>>>>>>>     data->trigger[i] =3D 0;
> >>>>>>>>>>
> >>>>>>>>>> would be replaced by
> >>>>>>>>>>
> >>>>>>>>>>>>>   else if ( evaluateAST(trigger, data) =3D=3D 0 )
> >>>>>>>>>>>>>     data->trigger[i] =3D 0;
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> ??
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> The double evaluation could be avoided by putting the
> >>>>>> evaluations
> >>>>>>>>>> within the if/else blocks:
> >>>>>>>>>>
> >>>>>>>>>> if ( data->trigger[i] =3D=3D 0 )
> >>>>>>>>>>    {
> >>>>>>>>>>    if ( evaluateAST(trigger, data) )
> >>>>>>>>>>      {
> >>>>>>>>>>        data->trigger[i] =3D 1;
> >>>>>>>>>>      }
> >>>>>>>>>>    }
> >>>>>>>>>> else /* only if trigger is 1 */
> >>>>>>>>>>    {
> >>>>>>>>>>      if ( !evaluateAST(trigger, data) )
> >>>>>>>>>>      {
> >>>>>>>>>>        data->trigger[i] =3D 0;
> >>>>>>>>>>      }
> >>>>>>>>>>    }
> >>>>>>>>>>
> >>>>>>>>>> but I don't see a way around the evaluation of=20
> each trigger.
> >>>>>>>>>>
> >>>>>>>>>> Do I get something wrong?
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Rainer
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> yours Andrew
> >>>>>>>>>>>
> >>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>> From: Rainer Machne [mailto:ra...@tb...]
> >>>>>>>>>>>> Sent: 12 April 2006 17:37
> >>>>>>>>>>>> To: Andrew Finney
> >>>>>>>>>>>> Cc: Christoph Flamm
> >>>>>>>>>>>> Subject: RE: comment on proposed exact event
> >>>>>>>>>> implementation[Scanned]
> >>>>>>>>>>>>
> >>>>>>>>>>>> Andrew
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Wed, 12 Apr 2006, Andrew Finney wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Rainer
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> below is all correct
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> it will make our model run slower or even=20
> incorrectly but
> >>>>>>>>>> I'll work
> >>>>>>>>>>>>> around it perhaps we'll need yet another option.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> The current implementation
> >>>>>>>>>>>>
> >>>>>>>>>>>>>   if ( data->trigger[i] =3D=3D 0 &&
> >> evaluateAST(trigger, data) )
> >>>>>>>>>>>>>     fired++; (leading to assignment execution in
> >>>> calling code)
> >>>>>>>>>>>>>     data->trigger[i] =3D 1;
> >>>>>>>>>>>>>   else
> >>>>>>>>>>>>>     data->trigger[i] =3D 0;
> >>>>>>>>>>>>
> >>>>>>>>>>>> means that event triggers are set to 0, whenever they
> >>>>>>>> have already
> >>>>>>>>>>>> been fired, even when the trigger is still true.
> >>>>>>>>>>>>
> >>>>>>>>>>>> That means that events are again executed in the=20
> time step=20
> >>>>>>>>>>>> afterwards, even if they have been true ever since
> >>>> their last
> >>>>>>>>>>>> execution.
> >>>>>>>>>>>> It is a completely wrong interpretation of events!
> >>>>>>>>>>>>
> >>>>>>>>>>>> Does your model really require this?
> >>>>>>>>>>>>
> >>>>>>>>>>>> As in the very old version, triggers should be
> >>>>>> evaluated before
> >>>>>>>>>>>> integration and only set to 0 if they are really false.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Rainer
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>>>> From: Rainer Machne [mailto:ra...@tb...]
> >>>>>>>>>>>>>> Sent: 12 April 2006 17:15
> >>>>>>>>>>>>>> To: Andrew Finney
> >>>>>>>>>>>>>> Cc: Christoph Flamm
> >>>>>>>>>>>>>> Subject: RE: comment on proposed exact event
> >>>>>>>>>>>> implementation[Scanned]
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Andrew
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Why do we cheat? As I remember, we do exactly the
> >>>>>>>>>> above for the
> >>>>>>>>>>>>>>>> inexact event handling!
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I have not got the code in front of me...
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> It was more correct in a very old version and=20
> seems to be
> >>>>>>>>>>>> incorrect
> >>>>>>>>>>>>>> for a while now!
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> In the former file odeIntegrate.c did:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> the function integrate() did
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>    for ( i=3D0; i<data->nt; i++ ) {
> >>>>>>>>>>>>>>      data->flag[i] =3D=20
> evaluateAST(data->trigger[i],data);
> >>>>>>>>>>>>>>    }
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> before integration, i.e. evaluate trigger state at
> >>>>>> time 0. So
> >>>>>>>>>>>>>> triggers that are already true are set to 1,=20
> others to 0.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Then in the integration loop the function checkTrigger
> >>>>>>>>>> was called
> >>>>>>>>>>>>>> after the CVode call. It did
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>      if(evaluateAST(data->trigger[i],data)=3D=3D0)
> >>>>>>>>>>>>>>      {
> >>>>>>>>>>>>>>        data->flag[i] =3D 0;
> >>>>>>>>>>>>>>      }
> >>>>>>>>>>>>>>      else if((data->flag[i]=3D=3D0) &&
> >>>>>>>>>>>>>> (evaluateAST(data->trigger[i],data)=3D=3D1))
> >>>>>>>>>>>>>>      {
> >>>>>>>>>>>>>>        data->flag[i] =3D 1;
> >>>>>>>>>>>>>>        ...
> >>>>>>>>>>>>>>      }
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> So trigger flags were set to 0 only when the trigger
> >>>>>>>>>> condition is
> >>>>>>>>>>>>>> really false and to 1 as soon as they become true.
> >>>>>> They stay 1
> >>>>>>>>>>>>>> (eventually having been set at time 0) as long
> >> as they are
> >>>>>>>>>>>> true, but
> >>>>>>>>>>>>>> their assignments are only evaluated when they
> >>>> were 0 before.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> This should do it, right?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> In the current version it is wrong:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> It's the line 636 in integratorInstance
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>   if ( data->trigger[i] =3D=3D 0 &&
> >>>> evaluateAST(trigger, data) )
> >>>>>>>>>>>>>>     fired++; (leading to assignment execution in
> >>>>>> calling code)
> >>>>>>>>>>>>>>     data->trigger[i] =3D 1;
> >>>>>>>>>>>>>>   else
> >>>>>>>>>>>>>>     data->trigger[i] =3D 0;
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I.e. it misses the evaluation for false
> >> triggers, but just
> >>>>>>>>>>>> sets any
> >>>>>>>>>>>>>> trigger false that was true, even if they are=20
> still true.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> It might just require to add
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>   else if ( evaluateAST(trigger, data) =3D=3D 0 )
> >>>>>>>>>>>>>>     data->trigger[i] =3D 0;
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> instead of the simple else.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Right?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> We should correct that for the simple event handling!
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> I have to think about the other stuff.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Rainer
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> you wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> This can become tricky. As far as I=20
> understood the root
> >>>>>>>>>>>> finder, it
> >>>>>>>>>>>>>>>> stops integrating at the time where it found=20
> the root.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Thus we might have to include a code
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> if ( triggerWasTrue )
> >>>>>>>>>>>>>>>>   rootFunction =3D 1.0;
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> to suppress root finding for triggers that are
> >>>>>> already true.
> >>>>>>>>>>>>>>>> The same should probably be done for combined
> >>>>>>>>>> triggers, for the
> >>>>>>>>>>>>>>>> expression that becomes true first and needs
> >> to wait for
> >>>>>>>>>>>> the second
> >>>>>>>>>>>>>>>> (or all) other inequalities of the trigger.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> My understanding is that the root finder only detects
> >>>>>>>>>> transitions
> >>>>>>>>>>>>>>> because x < 10 maps to x - 10 =3D=3D 0.  The root is =
only
> >>>>>>>>>> true at the
> >>>>>>>>>>>>>>> transition not at all points x < 10.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I think we need to be very careful about when and how
> >>>>>>>>>> we suppress
> >>>>>>>>>>>>>>> root expressions.  Any suppression inevitably=20
> means you
> >>>>>>>>>>>> potentially
> >>>>>>>>>>>>>>> miss a transition.  Having written that I=20
> don't know the
> >>>>>>>>>>>> theory but
> >>>>>>>>>>>>>>> I intuitively think that its not possible to resolve
> >>>>>>>> very close
> >>>>>>>>>>>>>>> transitions.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> The issues that I think we need to look out for are:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> a) restarting integration where the root is still true
> >>>>>>>>>>>>>>>    we might get stuck there!
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> 	Is that what you were worried about?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>    either fingers crossed cvode will ignore=20
> the initial
> >>>>>>>>>>>>>> state when root
> >>>>>>>>>>>>>>> finding
> >>>>>>>>>>>>>>>    or if not we might need to nudge forward by
> >> an epsilon
> >>>>>>>>>>>> with root
> >>>>>>>>>>>>>>> finding switched off :-(
> >>>>>>>>>>>>>>> 	(the algorithm I posted didn't include
> >> this concept)
> >>>>>>>>>>>>>>>    this might be a good idea since it forces time
> >>>>>>>>>> forward and the
> >>>>>>>>>>>>>>> simulation out of deadlocks.
> >>>>>>>>>>>>>>>    the problem is choosing an epsilon.  I=20
> guess it could
> >>>>>>>>>>>> be a very
> >>>>>>>>>>>>>>> small fraction of the time step length.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>    Perhaps this should be a constant set by=20
> the user: it
> >>>>>>>>>>>>>> represents the
> >>>>>>>>>>>>>>> minimum gap between event transitions.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> b) the integration, correctly, settles in a state with
> >>>>>>>>>> a root true
> >>>>>>>>>>>>>>> 	this untypical behaviour but could
> >> happen. it would be
> >>>>>>>>>>>> nice not to
> >>>>>>>>>>>>>>> blow up
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> 	this should be a test case
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> 	e.g. x tends to 10 with a trigger x < 10
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>    The problem is that the algorithm may end up
> >> being very
> >>>>>>>>>>>>>> inefficient
> >>>>>>>>>>>>>>> in this case.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> 	ideally the nudge described above needs to be
> >>>>>>>>>>>> proportional to the
> >>>>>>>>>>>>>>> internal cvode step size
> >>>>>>>>>>>>>>> 	can we get the internal integration step size
> >>>>>>>>>> from cvode?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> c) a model with an event based feedback loop=20
> that drives
> >>>>>>>>>>>>>> the model to a
> >>>>>>>>>>>>>>> state where events
> >>>>>>>>>>>>>>> 	are firing all the time.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> yours Andrew
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>>>>>> From: Rainer Machne [mailto:ra...@tb...]
> >>>>>>>>>>>>>>>> Sent: 12 April 2006 15:51
> >>>>>>>>>>>>>>>> To: Andrew Finney
> >>>>>>>>>>>>>>>> Cc: Christoph Flamm
> >>>>>>>>>>>>>>>> Subject: RE: comment on proposed exact event
> >>>>>>>>>>>>>> implementation[Scanned]
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Andrew
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On Wed, 12 Apr 2006, Andrew Finney wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Rainer
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> a trigger can contain inequality and equality
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> but they are found by equivalent root=20
> expressions so I
> >>>>>>>>>>>> don't think
> >>>>>>>>>>>>>>>>> they are important
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Oh there is one other really important issue:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> We need to be careful about the SBML=20
> requirement that
> >>>>>>>>>>>> events are
> >>>>>>>>>>>>>>>>> triggered on all transitions from false to true
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> In MathSBML Bruce Shapiro created following logic
> >>>>>>> roughly<
> >>>>>>>>>>>>>>>> (assume no
> >>>>>>>>>>>>>>>>> delays on events)
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> starting integration....
> >>>>>>>>>>>>>>>>>    triggerWasTrue =3D false;
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> OnRootFound:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>    if (triggerExpression and !triggerWasTrue)
> >>>>>>>>>>>>>>>>>    {
> >>>>>>>>>>>>>>>>>        fire event;
> >>>>>>>>>>>>>>>>>        triggerWasTrue =3D true;
> >>>>>>>>>>>>>>>>>    }
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>    if (!triggerExpression)
> >>>>>>>>>>>>>>>>>        triggerWasTrue =3D false;
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> We kind achive this in the inexact method but
> >>>> its really a
> >>>>>>>>>>>>>>>> cheat the
> >>>>>>>>>>>>>>>>> above I think is the only way to do it properly...
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Why do we cheat? As I remember, we do exactly the
> >>>>>>>>>> above for the
> >>>>>>>>>>>>>>>> inexact event handling!
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> The exact detection/root finder code needs to
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> * do the same, i.e. handle false/true
> >> transitions when a
> >>>>>>>>>>>>>> root is found
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> and additionally
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> * handle triggers that are (logic) combinations of
> >>>>>>>>>>>>>> in/equalities, i.e.
> >>>>>>>>>>>>>>>>    both must be true.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> In/equalities combined by logic operators can
> >> further be
> >>>>>>>>>>>>>> subdivided:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> e.g.:
> >>>>>>>>>>>>>>>> trigger a < 10 || b > 20
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> can be handled as two separate triggers, while and
> >>>>>>>>>> exclusive OR
> >>>>>>>>>>>>>>>> needs combined handling again as outlined before:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> e.g.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> trigger: a < 10 && b > 20
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> becomes to root conditions in the function g:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> a - 10 =3D 0;
> >>>>>>>>>>>>>>>> b - 20 =3D 0;
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> * keep integrating if only  a or b is true
> >>>>>>>>>>>>>>>> * exact event happens when the second conditions also
> >>>>>>>>>>>> becomes true
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> This can become tricky. As far as I=20
> understood the root
> >>>>>>>>>>>> finder, it
> >>>>>>>>>>>>>>>> stops integrating at the time where it found=20
> the root.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Thus we might have to include a code
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> if ( triggerWasTrue )
> >>>>>>>>>>>>>>>>   rootFunction =3D 1.0;
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> to supress root finding for triggers that are
> >>>> already true.
> >>>>>>>>>>>>>>>> The same should probably be done for combined
> >>>>>>>>>> triggers, for the
> >>>>>>>>>>>>>>>> expression that becomes true first and needs
> >> to wait for
> >>>>>>>>>>>> the second
> >>>>>>>>>>>>>>>> (or all) other inequalities of the trigger.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Rainer
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> yours Andrew
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>>>>>>>> From: Rainer Machne [mailto:ra...@tb...]
> >>>>>>>>>>>>>>>>>> Sent: 12 April 2006 15:21
> >>>>>>>>>>>>>>>>>> To: Christoph Flamm
> >>>>>>>>>>>>>>>>>> Cc: Andrew Finney
> >>>>>>>>>>>>>>>>>> Subject: RE: comment on proposed exact event
> >>>>>>>>>>>>>>>> implementation[Scanned]
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Hi Xtof,
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On Wed, 12 Apr 2006, Christoph Flamm wrote:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> hi andrew,
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> am i getting that right, in essence the recipe
> >>>>>> to evaluate
> >>>>>>>>>>>>>>>>>> letfChild -
> >>>>>>>>>>>>>>>>>>> rightChild works in general to find the exact
> >>>>>> timepoint of
> >>>>>>>>>>>>>>>>>> the event
> >>>>>>>>>>>>>>>>>>> with root finding?
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> No, for this example of an event:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> e.g. a < 10 && b > 10 becomes 2 root
> >>>> expressions 10 - a
> >>>>>>>>>>>>>>>> =3D=3D 0 and b
> >>>>>>>>>>>>>>>>>> - 10  > =3D=3D 0
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> we need to separately evaluate both trigger
> >>>>>>>> conditions, i.e.
> >>>>>>>>>>>>>>>>>> as Andrew said the event trigger becomes 2 root
> >>>>>>>>>>>>>>>> expressions for the
> >>>>>>>>>>>>>>>>>> g(x,p,t) root finding function!!
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> That means that not every root found be the root
> >>>>>> finder is
> >>>>>>>>>>>>>>>> an event.
> >>>>>>>>>>>>>>>>>> For above event, the first (e.g. a) that moved
> >>>> beyond the
> >>>>>>>>>>>>>>>> threshold
> >>>>>>>>>>>>>>>>>> (10) must wait for the second (b) to also move
> >>>>>>>>>> beyond its own
> >>>>>>>>>>>>>>>>>> threshold. I.e. for such event structures the event
> >>>>>>>>>> assignment
> >>>>>>>>>>>>>>>>>> evaluation must wait until the second root.
> >>>>>>>>>>>>>>>>>> ... or somehow like this.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> ... let's try to formulate this generally:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> * An event trigger is a boolean expression, but can
> >>>>>>>>>> be a logic
> >>>>>>>>>>>>>>>>>> combination of different boolean expressions ... ?
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> * Only equalities and inequalities can be
> >>>>>> evaluated by our
> >>>>>>>>>>>>>>>> leftChild
> >>>>>>>>>>>>>>>>>> - rightChild =3D=3D 0 condition in the root =
function
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> * logic operators must be broken down into their
> >>>>>>>>>>>>>>>> in/equality relation
> >>>>>>>>>>>>>>>>>> (which must be in there somewhere??)
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> mmhm ... questions:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> 1) we only need to care about logic operators vs.
> >>>>>>>>>> in/equality
> >>>>>>>>>>>>>>>>>> operators ?
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> 2) must there be in/equalities in a trigger?
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Rainer
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> =3D;) xtof
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Andrew Finney writes:
> >>>>>>>>>>>>>>>>>>>> Rainer
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> First I assume you run-through a trigger=20
> expression
> >>>>>>>>>>>>>>>>>> separating out
> >>>>>>>>>>>>>>>>>>>> all the inequalities
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> e.g. a < 10 && b > 10 becomes 2 root
> >>>> expressions 10 - a
> >>>>>>>>>>>>>>>>>> =3D=3D 0 and b -
> >>>>>>>>>>>>>>>>>>>> 10 =3D=3D 0
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> when you find a root you re-evaluate the complete
> >>>>>>>>>>>>>>>> triggers to see
> >>>>>>>>>>>>>>>>>>>> what's really fired.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> or is there a better approach?
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Are there other forms of events, where this
> >>>> method can
> >>>>>>>>>>>>>>>>>> not be applied?
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Well there is equality e.g. x =3D=3D 40 I think
> >>>> that should
> >>>>>>>>>>>>>>>> work as x -
> >>>>>>>>>>>>>>>>>>>> 40 =3D=3D 0 Inequality is fine to you map x=20
> !=3D 40 to x
> >>>>>>>>>> - 40 =3D=3D 0
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> In both cases you need to revaluate the trigger
> >>>>>>>>>>>> expression but
> >>>>>>>>>>>>>>>>>>>> probably with an epsilon (especially
> >> equality) or you
> >>>>>>>>>>>>>>>> may have to
> >>>>>>>>>>>>>>>>>>>> force a value from 39.9999 to 40 after the root
> >>>>>>>>>>>>>> finding process.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> One thing to very careful of is time dependant
> >>>>>>>>>>>>>> expressions (ones
> >>>>>>>>>>>>>>>>>>>> containing the csymbol for time) not so=20
> much in the
> >>>>>>>>>>>>>> triggers but
> >>>>>>>>>>>>>>>>>>>> make sure time is set right when you roll
> >>>>>>>>>>>> integration back or
> >>>>>>>>>>>>>>>>>>>> forward...hopefully that's obvious.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> yours Andrew
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>>>>>>>>>>> From: Rainer Machne=20
> [mailto:ra...@tb...]
> >>>>>>>>>>>>>>>>>>>>> Sent: 12 April 2006 14:40
> >>>>>>>>>>>>>>>>>>>>> To: Christoph Flamm
> >>>>>>>>>>>>>>>>>>>>> Cc: Andrew Finney
> >>>>>>>>>>>>>>>>>>>>> Subject: Re: comment on proposed exact event=20
> >>>>>>>>>>>>>>>>>>>>> implementation[Scanned]
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Hi Andrew and Xtof
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> another question:
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Currently we tell the root function to
> >> evaluate the
> >>>>>>>>>>>> expression
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> leftChildofTrigger - rightChildOfTrigger
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> for which the root finder tries to find a
> >> root, i.e.
> >>>>>>>>>>>>>>>>>> time points
> >>>>>>>>>>>>>>>>>>>>> where this expression evaluates to 0.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> This is valid for event like
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> if x > 40
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> where the method will try find a time=20
> point where
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> x - 40 =3D=3D 0.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Is this generally valid? Are there=20
> other forms of
> >>>>>>>>>>>>>> events, where
> >>>>>>>>>>>>>>>>>>>>> this method can not be applied?
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Rainer
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> On Wed, 12 Apr 2006, Christoph Flamm wrote:
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> hi andrew,
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> yes, you are right root finding is the
> >> only proper
> >>>>>>>>>>>>>>>>>> way to detect
> >>>>>>>>>>>>>>>>>>>>>> events accurately. also the code we need
> >>>> to implement
> >>>>>>>>>>>>>>>>>> would be
> >>>>>>>>>>>>>>>>>>>>>> much simpler with root finding. the=20
> down side of
> >>>>>>>>>>>>>> this approach
> >>>>>>>>>>>>>>>>>>>>> is, that the
> >>>>>>>>>>>>>>>>>>>>>> integration with root finding turned on
> >> drastically
> >>>>>>>>>>>>>>>>>> slowes down
> >>>>>>>>>>>>>>>>>>>>>> the integration speed especially if we
> >>>> have a lot of
> >>>>>>>>>>>>>> triggers!
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> the other problem which we did not touch
> >> during the
> >>>>>>>>>>>>>>>>>>>>> hackathon is what
> >>>>>>>>>>>>>>>>>>>>>> happens if to events trigger exactely at the
> >>>>>>>>>> same time but
> >>>>>>>>>>>>>>>>>>>>>> influence each other.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> suppose the following two events:
> >>>>>>>>>>>>>>>>>>>>>> (1) if x > 20 then diminish the concentration
> >>>>>>>> of y to 10
> >>>>>>>>>>>>>>>>>>>>>> (2) if y > 20 then diminish the concentration
> >>>>>>>> of x to 10
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> this is something like a cyclic=20
> dependency of the
> >>>>>>>>>>>>>>>> events. if both
> >>>>>>>>>>>>>>>>>>>>>> events are triggered at the same time, which
> >>>>>>>>>>>>>>>>>> could happen,
> >>>>>>>>>>>>>>>>>>>>> what shall
> >>>>>>>>>>>>>>>>>>>>>> we do?  which ever event we execute first
> >>>>>>>> invalidates the
> >>>>>>>>>>>>>>>>>>>>> trigger for
> >>>>>>>>>>>>>>>>>>>>>> the second one.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> in such a case an priority ordering of the
> >>>>>>>>>> events is needed
> >>>>>>>>>>>>>>>>>>>>> to resolve
> >>>>>>>>>>>>>>>>>>>>>> the problem right? is an answer to=20
> something like
> >>>>>>>>>>>> that in the
> >>>>>>>>>>>>>>>>>>>>>> SBML specs?
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> i think that the method i suggested at
> >> the hackaton
> >>>>>>>>>>>>>>>>>> would give
> >>>>>>>>>>>>>>>>>>>>>> us a good balance between speed and=20
> "accuracy of
> >>>>>>>>>> the event
> >>>>>>>>>>>>>>>>>>>>> detection" (but
> >>>>>>>>>>>>>>>>>>>>>> the coding is more difficult!)
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> rainer suggested as an alternative to=20
> the mixed=20
> >>>>>>>>>>>>>>>>>>>>>> root-finding/non-root-finding strategy
> >> to make the
> >>>>>>>>>>>>>>>>>> integration
> >>>>>>>>>>>>>>>>>>>>>> step smaller until the exact time of=20
> an event is
> >>>>>>>>>>>>>>>>>> localized (this
> >>>>>>>>>>>>>>>>>>>>> also slows
> >>>>>>>>>>>>>>>>>>>>>> down integration speed).
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> so for which solution should we head?
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> =3D;) xtof
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> p.s. next week i meet an mathematician from the
> >>>>>>>>>>>>>>>>>> MPI-MIS who is
> >>>>>>>>>>>>>>>>>>>>>> an expert for DDEs to discuss which
> >> solving method
> >>>>>>>>>>>>>>>>>> would be best
> >>>>>>>>>>>>>>>>>>>>>> to incooporate into the SOSlib.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> -------------------------------------------------------
> >>>>> 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=20
> v.1.0.1 based on=20
> >>>>> Apache Geronimo
> >>>>>
> >>>>
> >>=20
> http://sel.as-us.falkag.net/sel?cmd__________________________________
> >>>> _
> >>>>> ____________
> >>>>> 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,=20
> >> security?
> >> Get stuff done quickly with pre-integrated technology to make your=20
> >> job easier Download IBM WebSphere Application Server
> >> v.1.0.1 based on Apache Geronimo
> >> =
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&
> >> dat=3D121642
> >> _______________________________________________
> >> sbmlsolver-devel mailing list
> >> sbm...@li...
> >> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
> >>
> >
>=20