Menu
▾
▴
Re: [SOSlib-devel] RE: comment on proposed exact event implementation[Scanned]
|
From: Christoph F. <xt...@tb...> - 2006-04-19 13:31:39
|
hi Rainer,
i also have the declaration, and my cvs is in sync too
=;) xtof
Andrew Finney writes:
> Rainer
>
> strange
>
> I have the declaration at
> 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...]
> > 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
> > 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 `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
> > 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] = 0;
> > >>>>
> > >>>> would be replaced by
> > >>>>
> > >>>>>>> else if ( evaluateAST(trigger, data) == 0 )
> > >>>>>>> data->trigger[i] = 0;
> > >>>>
> > >>>>
> > >>>> ??
> > >>>>
> > >>>>
> > >>>> The double evaluation could be avoided by putting the
> > evaluations
> > >>>> within the if/else blocks:
> > >>>>
> > >>>> if ( data->trigger[i] == 0 )
> > >>>> {
> > >>>> if ( evaluateAST(trigger, data) )
> > >>>> {
> > >>>> data->trigger[i] = 1;
> > >>>> }
> > >>>> }
> > >>>> else /* only if trigger is 1 */
> > >>>> {
> > >>>> if ( !evaluateAST(trigger, data) )
> > >>>> {
> > >>>> data->trigger[i] = 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] == 0 && evaluateAST(trigger, data) )
> > >>>>>>> fired++; (leading to assignment execution in calling code)
> > >>>>>>> data->trigger[i] = 1;
> > >>>>>>> else
> > >>>>>>> data->trigger[i] = 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
> > >>>>>> 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=0; i<data->nt; i++ ) {
> > >>>>>>>> data->flag[i] = 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)==0)
> > >>>>>>>> {
> > >>>>>>>> data->flag[i] = 0;
> > >>>>>>>> }
> > >>>>>>>> else if((data->flag[i]==0) &&
> > >>>>>>>> (evaluateAST(data->trigger[i],data)==1))
> > >>>>>>>> {
> > >>>>>>>> data->flag[i] = 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] == 0 && evaluateAST(trigger, data) )
> > >>>>>>>> fired++; (leading to assignment execution in
> > calling code)
> > >>>>>>>> data->trigger[i] = 1;
> > >>>>>>>> else
> > >>>>>>>> data->trigger[i] = 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) == 0 )
> > >>>>>>>> data->trigger[i] = 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 = 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 == 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 = false;
> > >>>>>>>>>>>
> > >>>>>>>>>>> OnRootFound:
> > >>>>>>>>>>>
> > >>>>>>>>>>> if (triggerExpression and !triggerWasTrue)
> > >>>>>>>>>>> {
> > >>>>>>>>>>> fire event;
> > >>>>>>>>>>> triggerWasTrue = true;
> > >>>>>>>>>>> }
> > >>>>>>>>>>>
> > >>>>>>>>>>> if (!triggerExpression)
> > >>>>>>>>>>> triggerWasTrue = 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 = 0;
> > >>>>>>>>>> b - 20 = 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 = 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
> > >>>>>>>>>> == 0 and b
> > >>>>>>>>>>>> - 10 > == 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 == 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
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> =;) 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
> > >>>>>>>>>>>> == 0 and b -
> > >>>>>>>>>>>>>> 10 == 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 == 40 I think that should
> > >>>>>>>>>> work as x -
> > >>>>>>>>>>>>>> 40 == 0 Inequality is fine to you map x != 40 to x
> > >>>> - 40 == 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
> > >>>>>>>>>>>>>>> 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 == 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
> > >>>>>>>>>>>>>>>> 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?
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> =;) 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 v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd_______________________________________________
> sbmlsolver-devel mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
--
Christoph Flamm
Bioinformatik, Inst.f.Informatik, Univ.Leipzig, Germany
www: http://www.tbi.univie.ac.at/~xtof
phone: ++49 341 97-16688 fax: ++49 341 97-16709
email: xt...@bi...
smail: Haertelstrasse 16-18, D-04107 Leipzig, Germany
|
