Menu
▾
▴
RE: [SOSlib-devel] RE: comment on proposed exact event implementation[Scanned]
|
From: Andrew F. <af...@ph...> - 2006-04-19 13:40:18
|
Rainer
IntegratorInstance_processEventsAndAssignments
doesn't have a declaration: its not required as its not part of the API
the SBML_ODESOLVER_API qualification is redundant - I guess that
confused you
That's my fault. Remind me to update the dynalically compiled version
of this function.
you're probably OK as far as CVS goes
Andrew
> -----Original Message-----
> From: Rainer Machne [mailto:ra...@tb...]=20
> Sent: 19 April 2006 14:35
> To: Andrew Finney
> Cc: SOSlib Development
> Subject: Re: [SOSlib-devel] RE: comment on proposed exact=20
> event implementation[Scanned]
>=20
>=20
> On Wed, 19 Apr 2006, Andrew Finney wrote:
>=20
> > Rainer
> >
> > strange
> >
> > I have the declaration at
> > SBML_odeSolver\src\sbmlsolver\integratorInstance.h line 143
>=20
> At line 143 I only have a declaration for=20
> IntegratorInstance_integrateOneStepWithoutEventProcessing
>=20
> but can't find a declaration for
> IntegratorInstance_processEventsAndAssignments
>=20
> >
> > my CVS is saying that I'm in sync
> >
> > what do you have?
>=20
> mine too. that's really strange. Maybe cvs update checks only=20
> for version numbers and there is a problem with that?
>=20
> I have v 1.27 2006/04/11 13:10:45 afinney
>=20
> Strangely, the only CVS has version 1.26 from 5 weeks ago,=20
> while other files there are more recent.
>=20
> Rainer
>=20
> >
> > 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=20
> implementation[Scanned]
> >>
> >> Andrew
> >>
> >> I have correct the simple event detection, so that it 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 II_integrateOneStepWithoutEventProcessing,
> >> respectively, the functions
> >>
> >> II_simpleOneStep and II_cvodeOneStep
> >>
> >> shouldn't be public anymore.
> >>
> >> Before this new switch, they were public, so that=20
> applications which=20
> >> knew what type of solver is required (currently ODEs or no=20
> ODEs, but=20
> >> 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=20
> keep the=20
> >> possibility to use different solvers directly?
> >>
> >> In the second case we need to move the=20
> engine->processEvents setting=20
> >> to some other place!
> >>
> >> Also I didn't find a function declaration for=20
> >> II_integrateOneStepWithoutEventProcessing. I guess you 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=20
> 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 -=20
> as outlined=20
> >>>> 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 && evaluateAST(trigger, =
data) )
> >>>>>>>>> fired++; (leading to assignment execution in=20
> 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=20
> 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
> >> 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 as they are
> >>>>>>>> true, but
> >>>>>>>>>> their assignments are only evaluated when they=20
> 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 &&=20
> 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 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 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
> >>> 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=20
> 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=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.
> >>>>>>>>>>>>
> >>>>>>>>>>>> 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=20
> 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=20
> 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=20
> 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=20
> method can
> >>>>>>>>>>>>>> not be applied?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Well there is equality e.g. x =3D=3D 40 I think=20
> 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=20
> 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=20
> 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.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
> >
> > -------------------------------------------------------
> > Using Tomcat but need to do more? Need to support web=20
> services, security?
> > Get stuff done quickly with pre-integrated technology to=20
> make your job=20
> > easier Download IBM WebSphere Application Server v.1.0.1 based on=20
> > Apache Geronimo=20
> >=20
> http://sel.as-us.falkag.net/sel?cmd___________________________________
> > ____________
> > sbmlsolver-devel mailing list
> > sbm...@li...
> > https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
> >
>=20
|
