[SOSlib-devel] RE: comment on proposed exact event implementation[Scanned]

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

Rainer

strange

I have the declaration at=20
SBML_odeSolver\src\sbmlsolver\integratorInstance.h line 143

my CVS is saying that I'm in sync

what do you have?

yours Andrew

> -----Original Message-----
> From: Rainer Machne [mailto:ra...@tb...]=20
> Sent: 19 April 2006 12:42
> To: Andrew Finney
> Cc: SOSlib Development
> Subject: RE: comment on proposed exact event implementation[Scanned]
>=20
> Andrew
>=20
> I have correct the simple event detection, so that it doesn't=20
> set trigger flags to 0, if the trigger is actually still fired.
>=20
> Some questions regarding the new code:
>=20
> Now that enginge->processEvents is set either to 1 or to 0 in=20
> II_integrateOneStep and II_integrateOneStepWithoutEventProcessing,
> respectively, the functions
>=20
> II_simpleOneStep and II_cvodeOneStep
>=20
> shouldn't be public anymore.
>=20
> Before this new switch, they were public, so that=20
> applications which knew what type of solver is required=20
> (currently ODEs or no ODEs, but eventually also DAEs or even=20
> stochastic solvers) can use these `solver'OneStep functions directly.
>=20
> Should we remove these functions from the API or should we=20
> keep the possibility to use different solvers directly?
>=20
> In the second case we need to move the engine->processEvents=20
> setting to some other place!
>=20
> Also I didn't find a function declaration for=20
> II_integrateOneStepWithoutEventProcessing. I guess you wanted=20
> this function to be public, or did you just use it for testing?
>=20
>=20
> Rainer
>=20
>=20
>=20
>=20
> On Wed, 19 Apr 2006, Andrew Finney wrote:
>=20
> > 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=20
> implementation[Scanned]
> >>
> >> Andrew
> >>
> >>> I'm more worried about the performance hit of evaluating the not=20
> >>> trigger expression.
> >>
> >> Ok, I still don't get what you mean.
> >>
> >> Do you mind, if I correct the current event handling - as outlined=20
> >> two emails below - and submit it, or do you think it would=20
> slow down=20
> >> 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=20
> evaluating the not=20
> >>>>> 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=20
> evaluations=20
> >>>> 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 && 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=20
> >>>>>> execution.
> >>>>>> It is a completely wrong interpretation of events!
> >>>>>>
> >>>>>> Does your model really require this?
> >>>>>>
> >>>>>> As in the very old version, triggers should be=20
> evaluated before=20
> >>>>>> 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=20
> time 0. So=20
> >>>>>>>> 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.=20
> They stay 1=20
> >>>>>>>> (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=20
> 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 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=20
> 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 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 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 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 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 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=20
> >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 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 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=20
> to evaluate
> >>>>>>>>>>>> letfChild -
> >>>>>>>>>>>>> rightChild works in general to find the exact=20
> 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=20
> 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=20
> 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 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 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 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 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 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 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 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 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 solving method
> >>>>>>>>>>>> would be best
> >>>>>>>>>>>>>>>> to incooporate into the SOSlib.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
>=20