Menu
▾
▴
Re: [SOSlib-devel] RE: comment on proposed exact event implementation[Scanned]
|
From: Rainer M. <ra...@tb...> - 2006-04-19 13:35:36
|
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
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 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 other
files there are more recent.
Rainer
>
> yours Andrew
>
>> -----Original Message-----
>> From: Rainer Machne [mailto:ra...@tb...]
>> Sent: 19 April 2006 12:42
>> To: Andrew Finney
>> Cc: SOSlib Development
>> Subject: RE: comment on proposed exact event implementation[Scanned]
>>
>> Andrew
>>
>> I have correct the simple event detection, so that it doesn't
>> set trigger flags to 0, if the trigger is actually still fired.
>>
>> Some questions regarding the new code:
>>
>> Now that enginge->processEvents is set either to 1 or to 0 in
>> 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
>
|
