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

[Rainer M. <ra...@tb...>]

Andrew

On Wed, 19 Apr 2006, Andrew Finney wrote:

> 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

Exactly, that was it. Sorry for the confusion.

I understand, that it isn't required to declare such functions, if they 
are defined before the are used.

Would people support a convention that we still declare such private 
functions in the header of the c file, in which they are used?

This would also allow to put private functions all together outside of a 
doxygen documentation block. Otherwise the functions will be included in 
the documentation, or have each to be surrounded by end/start tags for 
documentation blocks.

Rainer


> 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...]
>> Sent: 19 April 2006 14:35
>> To: Andrew Finney
>> Cc: SOSlib Development
>> Subject: Re: [SOSlib-devel] RE: comment on proposed exact
>> event implementation[Scanned]
>>
>>
>> On Wed, 19 Apr 2006, Andrew Finney wrote:
>>
>>> Rainer
>>>
>>> strange
>>>
>>> I have the declaration at
>>> SBML_odeSolver\src\sbmlsolver\integratorInstance.h line 143
>>
>> At line 143 I only have a declaration for
>> 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
>>>
>>
>