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

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

Rainer

you wrote:

> * clean up the use of the SBML_ODESOLVER_API tag (part of C++=20
> API todo)

yes

>=20
> * decide wheter private functions should be declared at the=20
> header of the c file
>=20

see last email

> * remove redundant function II_checkTrigger or alternatively
> * provide this function as API -- maybe without the event execution ??
>=20
>=20

if it aint called get rid of it

> * decide on whether or not to have API functions for=20
> solverOneStep (for each solver, no ODES, CVODES, IDA, etc.)=20
> or if this should be handled inside the library and=20
> integrateOneStep will be the only API one step function
> =20

my preference is to have only one API one step function

yours Andrew

> -----Original Message-----
> From: sbm...@li...=20
> [mailto:sbm...@li...] On=20
> Behalf Of Rainer Machne
> Sent: 19 April 2006 14:56
> To: SOSlib Development
> Subject: [SOSlib-devel] simple event handling corrected[Scanned]
>=20
> Hi All
>=20
> Just wanted to let you know, that I have submitted a=20
> (hopefully) corrected version of the simple event handling.
>=20
> TODOs found:
>=20
> * clean up the use of the SBML_ODESOLVER_API tag (part of C++=20
> API todo)
>=20
> * decide wheter private functions should be declared at the=20
> header of the c file
>=20
> * remove redundant function II_checkTrigger or alternatively
> * provide this function as API -- maybe without the event execution ??
>=20
>=20
> * decide on whether or not to have API functions for=20
> solverOneStep (for each solver, no ODES, CVODES, IDA, etc.)=20
> or if this should be handled inside the library and=20
> integrateOneStep will be the only API one step function
>=20
> Rainer
>=20
>=20
>=20
>=20
> On Wed, 19 Apr 2006, Andrew Finney wrote:
>=20
> > Rainer
> >
> > IntegratorInstance_processEventsAndAssignments
> >
> > doesn't have a declaration: its not required as its not part of the=20
> > API the SBML_ODESOLVER_API qualification is redundant - I=20
> guess that=20
> > confused you That's my fault.  Remind me to update the 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 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=20
> doesn't set=20
> >>>> 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=20
> 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=20
> wanted this=20
> >>>> 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 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 incorrectly but
> >>>>>>>> I'll work
> >>>>>>>>>>> around it perhaps we'll need yet another option.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> The current implementation
> >>>>>>>>>>
> >>>>>>>>>>>   if ( data->trigger[i] =3D=3D 0 &&=20
> 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 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 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 =
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, 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=20
> 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=20
> triggers, but just
> >>>>>>>>>> sets any
> >>>>>>>>>>>> trigger false that was true, even if they are 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 understood the root
> >>>>>>>>>> finder, it
> >>>>>>>>>>>>>> stops integrating at the time where it found 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=20
> 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 means you
> >>>>>>>>>> potentially
> >>>>>>>>>>>>> miss a transition.  Having written that I 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 the initial
> >>>>>>>>>>>> state when root
> >>>>>>>>>>>>> finding
> >>>>>>>>>>>>>    or if not we might need to nudge forward by=20
> an epsilon
> >>>>>>>>>> with root
> >>>>>>>>>>>>> finding switched off :-(
> >>>>>>>>>>>>> 	(the algorithm I posted didn't include=20
> 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 guess it could
> >>>>>>>>>> be a very
> >>>>>>>>>>>>> small fraction of the time step length.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>    Perhaps this should be a constant set by 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=20
> 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=20
> 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 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 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 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=20
> 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=20
> 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 understood the root
> >>>>>>>>>> finder, it
> >>>>>>>>>>>>>> stops integrating at the time where it found 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=20
> 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 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 !=3D 40 =
to x
> >>>>>>>> - 40 =3D=3D 0
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> In both cases you need to revaluate the trigger
> >>>>>>>>>> expression but
> >>>>>>>>>>>>>>>>>> probably with an epsilon (especially=20
> 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 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 [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=20
> evaluate the
> >>>>>>>>>> expression
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> leftChildofTrigger - rightChildOfTrigger
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> for which the root finder tries to find a=20
> 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 point where
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> x - 40 =3D=3D 0.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Is this generally valid? Are there 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=20
> only proper
> >>>>>>>>>>>>>>>> way to detect
> >>>>>>>>>>>>>>>>>>>> events accurately. also the code we need
> >> to implement
> >>>>>>>>>>>>>>>> would be
> >>>>>>>>>>>>>>>>>>>> much simpler with root finding. the down side of
> >>>>>>>>>>>> this approach
> >>>>>>>>>>>>>>>>>>> is, that the
> >>>>>>>>>>>>>>>>>>>> integration with root finding turned on=20
> drastically
> >>>>>>>>>>>>>>>> slowes down
> >>>>>>>>>>>>>>>>>>>> the integration speed especially if we
> >> have a lot of
> >>>>>>>>>>>> triggers!
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> the other problem which we did not touch=20
> 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 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 something like
> >>>>>>>>>> that in the
> >>>>>>>>>>>>>>>>>>>> SBML specs?
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> i think that the method i suggested at=20
> the hackaton
> >>>>>>>>>>>>>>>> would give
> >>>>>>>>>>>>>>>>>>>> us a good balance between speed and "accuracy of
> >>>>>>>> the event
> >>>>>>>>>>>>>>>>>>> detection" (but
> >>>>>>>>>>>>>>>>>>>> the coding is more difficult!)
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> rainer suggested as an alternative to the mixed=20
> >>>>>>>>>>>>>>>>>>>> root-finding/non-root-finding strategy=20
> to make the
> >>>>>>>>>>>>>>>> integration
> >>>>>>>>>>>>>>>>>>>> step smaller until the exact time of 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=20
> 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 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
> >>>
> >>
> >
>=20
>=20
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web=20
> services, security?
> Get stuff done quickly with pre-integrated technology to make=20
> your job easier Download IBM WebSphere Application Server=20
> v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&
> dat=3D121642
> _______________________________________________
> sbmlsolver-devel mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>=20