sbmlsolver-devel — developer's email list for the SBML ODE Solver Library

Re: [SOSlib-devel] Bug in sensitivity analysis?

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

Hi Eryk,

On Thu, 11 May 2006, Witold Wolski wrote:

> Hi Rainer,
>
> The point I wanted to make is that I am wondering why depending if I use the
> function globalizeParameter or not prior to integration I am getting
> different results.

Sorry, I really didn't answer that question!

>> > globalizeParameter(model,"V2","J1");


By globalizing two parameters you add them to the cvodeData constants 
(nvalues and nconst increase by two) and thereby request more 
sensitivities from CVODES. Calculating many sensitivities at 
the same time can in some cases significantly decrease the performance or 
even get too much for CVODES and it quits.

`convergence failed' is the usual message when CVODES cannot calculate 
results (timecourses and/or sensitivities) within the requested error 
tolerance.

Unfortunately, the sensitivity error tolerance currently cannot be set, 
but you can try to play with the general tolerances (--error and --rerror) 
and with the maximum number of internal steps option (--mxstep) or with 
external steps (--printstep).

To solve this, we need to

a) implement a way to select specific parameters for which sensitivities 
are calculated; a quick hack could be a function localizeParameterExcept 
that works on the SBML input model and localizes all global parameters 
except the ones that you want sensititities for.

b) implement error settings for sensitivities


Furthermore, we need to write documentation on performance relevant 
settings, such as errors, mxstep etc.


Ok?

Rainer


>
> cheers
> Eryk
>
>
> On 5/10/06, Rainer Machne <ra...@tb...> wrote:
>> 
>> 
>> 
>> > If I do not call it the output reads:
>> >
>> > CVode-- At t = 0 and h = 1.12418e-06, the corrector
>> > convergence failed repeatedly or with |h| = hmin.
>> >
>> > 1.12418e-06  0 0 0 0 0 0 0 0
>> > 1.12418e-06  10  0 0 0 0
>> 
>> 
>> The first two lines mean that cvodes has failed for integration with
>> sensitivity analysis. Thus results and sensitivities were not calculated.
>> 
>> IntegratorInstance_dumpY/PSensitivities
>> 
>> print first the current time, then the current value of the
>> variable/parameter, and then the sensitivities to all constants of the
>> model.
>> 
>> I have never noticed however that upon failure the current time seems to
>> be the h, which is cvodes' internal timestep. So the sensitivities for
>> this time h are wrong and the output should look different. Maybe upon
>> failure cvodeData the time should be reset to the last valid time.
>> 
>> 
>> Rainer
>> 
>> On Wed, 10 May 2006, Witold Wolski wrote:
>> 
>> > Hello,
>> >
>> > Depending if I apply globalise parameter or not I am getting different
>> > outputs in the sensitivity analysis.
>> >
>> > Given the MAPK.xml
>> >
>> > Namely the output of the functions (see attachment)
>> >
>> > IntegratorInstance_dumpPSensitivities(integratorInstance,p1);
>> > IntegratorInstance_dumpYSensitivities(integratorInstance,y1);
>> >
>> > differs depedning if
>> >
>> > globalizeParameter(model,"V2","J1");
>> >
>> > was called.
>> >
>> > If I do not call it the output reads:
>> >
>> > CVode-- At t = 0 and h = 1.12418e-06, the corrector
>> > convergence failed repeatedly or with |h| = hmin.
>> >
>> > 1.12418e-06  0 0 0 0 0 0 0 0
>> > 1.12418e-06  10  0 0 0 0
>> >
>> > I am working on a very recent cvs checkout.
>> >
>> > cheers
>> >
>> > Eryk
>> >
>> 
>

Re: [SOSlib-devel] Bug in sensitivity analysis?

[Witold W. <wew...@gm...>]

Hi Rainer,

The point I wanted to make is that I am wondering why depending if I use th=
e
function globalizeParameter or not prior to integration I am getting
different results.

cheers
Eryk


On 5/10/06, Rainer Machne <ra...@tb...> wrote:
>
>
>
> > If I do not call it the output reads:
> >
> > CVode-- At t =3D 0 and h =3D 1.12418e-06, the corrector
> > convergence failed repeatedly or with |h| =3D hmin.
> >
> > 1.12418e-06  0 0 0 0 0 0 0 0
> > 1.12418e-06  10  0 0 0 0
>
>
> The first two lines mean that cvodes has failed for integration with
> sensitivity analysis. Thus results and sensitivities were not calculated.
>
> IntegratorInstance_dumpY/PSensitivities
>
> print first the current time, then the current value of the
> variable/parameter, and then the sensitivities to all constants of the
> model.
>
> I have never noticed however that upon failure the current time seems to
> be the h, which is cvodes' internal timestep. So the sensitivities for
> this time h are wrong and the output should look different. Maybe upon
> failure cvodeData the time should be reset to the last valid time.
>
>
> Rainer
>
> On Wed, 10 May 2006, Witold Wolski wrote:
>
> > Hello,
> >
> > Depending if I apply globalise parameter or not I am getting different
> > outputs in the sensitivity analysis.
> >
> > Given the MAPK.xml
> >
> > Namely the output of the functions (see attachment)
> >
> > IntegratorInstance_dumpPSensitivities(integratorInstance,p1);
> > IntegratorInstance_dumpYSensitivities(integratorInstance,y1);
> >
> > differs depedning if
> >
> > globalizeParameter(model,"V2","J1");
> >
> > was called.
> >
> > If I do not call it the output reads:
> >
> > CVode-- At t =3D 0 and h =3D 1.12418e-06, the corrector
> > convergence failed repeatedly or with |h| =3D hmin.
> >
> > 1.12418e-06  0 0 0 0 0 0 0 0
> > 1.12418e-06  10  0 0 0 0
> >
> > I am working on a very recent cvs checkout.
> >
> > cheers
> >
> > Eryk
> >
>

Re: [SOSlib-devel] Bug in sensitivity analysis?

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

> If I do not call it the output reads:
>
> CVode-- At t = 0 and h = 1.12418e-06, the corrector
> convergence failed repeatedly or with |h| = hmin.
>
> 1.12418e-06  0 0 0 0 0 0 0 0
> 1.12418e-06  10  0 0 0 0


The first two lines mean that cvodes has failed for integration with 
sensitivity analysis. Thus results and sensitivities were not calculated.

IntegratorInstance_dumpY/PSensitivities

print first the current time, then the current value of the 
variable/parameter, and then the sensitivities to all constants of the 
model.

I have never noticed however that upon failure the current time seems to 
be the h, which is cvodes' internal timestep. So the sensitivities for 
this time h are wrong and the output should look different. Maybe upon 
failure cvodeData the time should be reset to the last valid time.


Rainer

On Wed, 10 May 2006, Witold Wolski wrote:

> Hello,
>
> Depending if I apply globalise parameter or not I am getting different
> outputs in the sensitivity analysis.
>
> Given the MAPK.xml
>
> Namely the output of the functions (see attachment)
>
> IntegratorInstance_dumpPSensitivities(integratorInstance,p1);
> IntegratorInstance_dumpYSensitivities(integratorInstance,y1);
>
> differs depedning if
>
> globalizeParameter(model,"V2","J1");
>
> was called.
>
> If I do not call it the output reads:
>
> CVode-- At t = 0 and h = 1.12418e-06, the corrector
> convergence failed repeatedly or with |h| = hmin.
>
> 1.12418e-06  0 0 0 0 0 0 0 0
> 1.12418e-06  10  0 0 0 0
>
> I am working on a very recent cvs checkout.
>
> cheers
>
> Eryk
>

Re: [SOSlib-devel] Question regarding dimension of sensitivity matrix.

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

Hi Eryk,

sorry for still not having answered your previous emails.
Today was our last meeting for a while and I will have more time.

This one is answered fast.

> Why:
> integratorInstance->data->nsens == 4
> TRUE
>
> I would think that n->nsens should be 3 e.g.


because the model also has a compartment with size 1. Compartments in SBML 
are treated as constant parameters in odeModel.

Unfortunately we currently cannot do sens.analysis for selected parameters 
but for all parameters. Thus there is also a sensitivity for the 
compartment.

Rainer



On Wed, 10 May 2006, Witold Wolski wrote:

> Hi,
>
> Using example of the MAPK.xml model.
>
> The MAPK.xml model has 3 global parameters :
> <listOfParameters>
>                 <parameter name = "V1" value = "2.5"/>
>                 <parameter name = "Ki" value = "9"/>
>                  <parameter name = "K1" value = "10"/>
> </listOfParameters>
>
> Why:
> integratorInstance->data->nsens == 4
> TRUE
>
> I would think that n->nsens should be 3 e.g.
>
> dy1/dp1 dy1/dp2 dy1/dp3.
>
>
> cheers
> Eryk
>

[SOSlib-devel] Bug in sensitivity analysis?

[Witold W. <wew...@gm...>]

Hello,

Depending if I apply globalise parameter or not I am getting different
outputs in the sensitivity analysis.

Given the MAPK.xml

Namely the output of the functions (see attachment)

IntegratorInstance_dumpPSensitivities(integratorInstance,p1);
IntegratorInstance_dumpYSensitivities(integratorInstance,y1);

differs depedning if

globalizeParameter(model,"V2","J1");

was called.

If I do not call it the output reads:

CVode-- At t = 0 and h = 1.12418e-06, the corrector
convergence failed repeatedly or with |h| = hmin.

1.12418e-06  0 0 0 0 0 0 0 0
1.12418e-06  10  0 0 0 0

I am working on a very recent cvs checkout.

cheers

Eryk

[SOSlib-devel] Question regarding dimension of sensitivity matrix.

[Witold W. <wew...@gm...>]

Hi,

Using example of the MAPK.xml model.

The MAPK.xml model has 3 global parameters :
<listOfParameters>
                  <parameter name =3D "V1" value =3D "2.5"/>
                  <parameter name =3D "Ki" value =3D "9"/>
                   <parameter name =3D "K1" value =3D "10"/>
</listOfParameters>

Why:
integratorInstance->data->nsens =3D=3D 4
TRUE

I would think that n->nsens should be 3 e.g.

dy1/dp1 dy1/dp2 dy1/dp3.


cheers
Eryk

[SOSlib-devel] More questions.

[Witold W. <wew...@gm...>]

Hi soslib-developers,

Why  typedef struct variableIndex variableIndex_t;
is in odeModel.h
but:
struct variableIndex is in variableIndex.h ?

In order to use variableIndex_t. I have to include both h files.

cheers
Eryk

[SOSlib-devel] Coding conventions.

[Witold W. <wew...@gm...>]

Hi,

I am struggling to understand the code, not only because of its complexity
but also because, finding the next variable named for example m, r, k, om
etc. is tedious. Therefore, I would suggest to define a variable Model_t *
model_p instead of just Model_t *m. Using model_p as a variable name makes
it easy to find, makes clear that the variable is of type model,  and
finally that it is a pointer (_p). Any comments?

Eryk

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

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

Andrew

> I'm just stating my preference.  Its not a big deal.
> Its just something else that needs to updated that's all.
> I'm willing to support your idea if you feel strongly about it

I'm not really fealing strong about, i was just confused, because a while 
ago I thought that function declarations are obligatory.

Anyways, it should be unique within the project.

Another pro reason would be, that it makes it easier to get an overview of 
functions that have newly been introduced if you check out strongly 
modified/enhanced code.

So I'd prefer to have all declarations, but would accept a majority vote 
against it :-)

Is anyone else from the list still reading and willing to vote?

Rainer



On Wed, 19 Apr 2006, Andrew Finney wrote:

> Andrew
>
> I'm just stating my preference.  Its not a big deal.
> Its just something else that needs to updated that's all.
> I'm willing to support your idea if you feel strongly about it.
>
> yours Andrew
>
>> -----Original Message-----
>> From: Rainer Machne [mailto:ra...@tb...]
>> Sent: 19 April 2006 16:07
>> To: Andrew Finney
>> Cc: SOSlib Development
>> Subject: RE: [SOSlib-devel] RE: comment on proposed exact
>> event implementation[Scanned]
>>
>> Andrew
>>
>>> Mutually recursive functions require forward declarations e.g.:
>>
>> Of course. Thanks!
>>
>>
>>> if a forward declaration is required or if we decide we must have
>>> private prototypes (my preference no!) then the private
>> prototypes go
>>> in the relevant C file at the top of the file
>>
>> Can you explain why you don't like this? Is this a general
>> style question or can there be any problems with the
>> redundant declarations?
>>
>> As said, I like to have all existing functions listed
>> somewhere to keep the overview.
>>
>> But if this is not necessary/considered unstylish/problematic
>> in general, then I'll happily agree that redundancies are bad
>> - well, at least in code :-) .
>>
>> Rainer
>>
>>
>> On Wed, 19 Apr 2006, Andrew Finney wrote:
>>
>>> Rainer
>>>
>>> you wrote:
>>>
>>>> Can't you always just write the function before it is used?
>>>> Does this also
>>>> work for recursive functions? Sorry for my illiteracy with
>> such basic
>>>> stuff :-)
>>>
>>> Mutually recursive functions require forward declarations e.g.:
>>>
>>> void f();
>>>
>>> void g()
>>> {
>>>  f();
>>> }
>>>
>>> void f()
>>> {
>>>  g();
>>> }
>>>
>>>>> d) any other case is public!
>>>>
>>>> I.e. either in ...internal.h or in API .h files, right?
>>>
>>> if a forward declaration is required or if we decide we must have
>>> private prototypes (my preference no!) then the private
>> prototypes go
>>> in the relevant C file at the top of the file
>>>
>>> otherwise
>>>
>>> if the function is private to the library it goes in XXX_internal.h
>>>
>>> otherwise
>>>
>>> the function must be public/API so it goes in XXX.h
>>>
>>> OK?
>>>
>>> yours Andrew
>>>
>>>> -----Original Message-----
>>>> From: Rainer Machne [mailto:ra...@tb...]
>>>> Sent: 19 April 2006 15:25
>>>> To: Andrew Finney
>>>> Cc: SOSlib Development
>>>> Subject: RE: [SOSlib-devel] RE: comment on proposed exact event
>>>> implementation[Scanned]
>>>>
>>>> Andrew
>>>>
>>>> On Wed, 19 Apr 2006, Andrew Finney wrote:
>>>>>> Would people support a convention that we still declare
>>>> such private
>>>>>> functions in the header of the c file, in which they are used?
>>>>>>
>>>>>
>>>>> Hmmm
>>>>>
>>>>> Do you mean the .h file or the top section of the .c file?
>>>>
>>>> I meant the top section of the .c file.
>>>>
>>>>>
>>>>> my preference is for
>>>>>
>>>>> a) no redundant prototypes (simple is best) i.e. only
>> used where a
>>>>> forward declaration is needed
>>>>
>>>> Personally, I like to have nice lists of all existing
>> functions, i.e.
>>>> header files (.h) plus declarations at the top section of .c files
>>>> for static functions. It just makes it easier for me to recall the
>>>> exact order of function calls, without parsing throught the source.
>>>>
>>>> However, as it is not necessary for doxygen, we could remove all
>>>> declarations of static functions in .c file, if people wish so.
>>>>
>>>>
>>>>> b) if they are necessary they go in the .c file as a first resort
>>>>
>>>> I can't think of a case where this would be necessary, if the
>>>> function is only used within this .c file.
>>>>
>>>> Can't you always just write the function before it is used?
>>>> Does this also
>>>> work for recursive functions? Sorry for my illiteracy with
>> such basic
>>>> stuff :-)
>>>>
>>>>
>>>>> c) if they are required to be in a header but they are not
>>>> part of the
>>>>> API
>>>>>    they should go in a header like:  intergatorInstance_internal.h
>>>>>   In the long term we ought to separate the API
>> prototypes from the
>>>>>   internal prototypes in two separate sets of headers so that
>>>>> applications
>>>>>   can clearly see what is the API.
>>>>
>>>> Agree.
>>>>
>>>>
>>>>> d) any other case is public!
>>>>
>>>> I.e. either in ...internal.h or in API .h files, right?
>>>>
>>>>> e) don't use SBML_ODESOLVER_API unless the function is
>> strictly part
>>>>> of the API (I'm guilty too)
>>>>
>>>> Agree.
>>>>
>>>>
>>>>>
>>>>>> 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.
>>>>>
>>>>> Can you explain this in detail please?
>>>>> What do you mean 'outside of a doxygen documentation block'?
>>>>
>>>>
>>>> A doxygen documentation block starts with
>>>>
>>>>  	/*@{*/
>>>>
>>>> and ends with
>>>>
>>>>  	/*}@*/
>>>>
>>>>
>>>> However, I was wrong with the above statement.
>>>>
>>>> If the function does NOT contain any
>>>>
>>>>  	/** or /*!
>>>>
>>>> comments, then it will NOT be part of the documentation.
>>>>
>>>> Thus static and non API functions should ONLY use /* comments.
>>>>
>>>> I just corrected the doxygen template c file at
>>>> http://www.tbi.univie.ac.at/~raim/odeSolver/data/doxygenComments.c
>>>>
>>>> Rainer
>>>>
>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Rainer Machne [mailto:ra...@tb...]
>>>>>> Sent: 19 April 2006 14:48
>>>>>> To: Andrew Finney
>>>>>> Cc: SOSlib Development
>>>>>> Subject: RE: [SOSlib-devel] RE: comment on proposed exact event
>>>>>> implementation[Scanned]
>>>>>>
>>>>>> 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
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
>
> -------------------------------------------------------
> 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
>

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

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

Andrew

I'm just stating my preference.  Its not a big deal.
Its just something else that needs to updated that's all.
I'm willing to support your idea if you feel strongly about it.

yours Andrew=20

> -----Original Message-----
> From: Rainer Machne [mailto:ra...@tb...]=20
> Sent: 19 April 2006 16:07
> To: Andrew Finney
> Cc: SOSlib Development
> Subject: RE: [SOSlib-devel] RE: comment on proposed exact=20
> event implementation[Scanned]
>=20
> Andrew
>=20
> > Mutually recursive functions require forward declarations e.g.:
>=20
> Of course. Thanks!
>=20
>=20
> > if a forward declaration is required or if we decide we must have=20
> > private prototypes (my preference no!) then the private=20
> prototypes go=20
> > in the relevant C file at the top of the file
>=20
> Can you explain why you don't like this? Is this a general=20
> style question or can there be any problems with the=20
> redundant declarations?
>=20
> As said, I like to have all existing functions listed=20
> somewhere to keep the overview.
>=20
> But if this is not necessary/considered unstylish/problematic=20
> in general, then I'll happily agree that redundancies are bad=20
> - well, at least in code :-) .
>=20
> Rainer
>=20
>=20
> On Wed, 19 Apr 2006, Andrew Finney wrote:
>=20
> > Rainer
> >
> > you wrote:
> >
> >> Can't you always just write the function before it is used?
> >> Does this also
> >> work for recursive functions? Sorry for my illiteracy with=20
> such basic=20
> >> stuff :-)
> >
> > Mutually recursive functions require forward declarations e.g.:
> >
> > void f();
> >
> > void g()
> > {
> >  f();
> > }
> >
> > void f()
> > {
> >  g();
> > }
> >
> >>> d) any other case is public!
> >>
> >> I.e. either in ...internal.h or in API .h files, right?
> >
> > if a forward declaration is required or if we decide we must have=20
> > private prototypes (my preference no!) then the private=20
> prototypes go=20
> > in the relevant C file at the top of the file
> >
> > otherwise
> >
> > if the function is private to the library it goes in XXX_internal.h
> >
> > otherwise
> >
> > the function must be public/API so it goes in XXX.h
> >
> > OK?
> >
> > yours Andrew
> >
> >> -----Original Message-----
> >> From: Rainer Machne [mailto:ra...@tb...]
> >> Sent: 19 April 2006 15:25
> >> To: Andrew Finney
> >> Cc: SOSlib Development
> >> Subject: RE: [SOSlib-devel] RE: comment on proposed exact event=20
> >> implementation[Scanned]
> >>
> >> Andrew
> >>
> >> On Wed, 19 Apr 2006, Andrew Finney wrote:
> >>>> Would people support a convention that we still declare
> >> such private
> >>>> functions in the header of the c file, in which they are used?
> >>>>
> >>>
> >>> Hmmm
> >>>
> >>> Do you mean the .h file or the top section of the .c file?
> >>
> >> I meant the top section of the .c file.
> >>
> >>>
> >>> my preference is for
> >>>
> >>> a) no redundant prototypes (simple is best) i.e. only=20
> used where a=20
> >>> forward declaration is needed
> >>
> >> Personally, I like to have nice lists of all existing=20
> functions, i.e.
> >> header files (.h) plus declarations at the top section of .c files=20
> >> for static functions. It just makes it easier for me to recall the=20
> >> exact order of function calls, without parsing throught the source.
> >>
> >> However, as it is not necessary for doxygen, we could remove all=20
> >> declarations of static functions in .c file, if people wish so.
> >>
> >>
> >>> b) if they are necessary they go in the .c file as a first resort
> >>
> >> I can't think of a case where this would be necessary, if the=20
> >> function is only used within this .c file.
> >>
> >> Can't you always just write the function before it is used?
> >> Does this also
> >> work for recursive functions? Sorry for my illiteracy with=20
> such basic=20
> >> stuff :-)
> >>
> >>
> >>> c) if they are required to be in a header but they are not
> >> part of the
> >>> API
> >>>    they should go in a header like:  intergatorInstance_internal.h
> >>>   In the long term we ought to separate the API=20
> prototypes from the
> >>>   internal prototypes in two separate sets of headers so that=20
> >>> applications
> >>>   can clearly see what is the API.
> >>
> >> Agree.
> >>
> >>
> >>> d) any other case is public!
> >>
> >> I.e. either in ...internal.h or in API .h files, right?
> >>
> >>> e) don't use SBML_ODESOLVER_API unless the function is=20
> strictly part=20
> >>> of the API (I'm guilty too)
> >>
> >> Agree.
> >>
> >>
> >>>
> >>>> This would also allow to put private functions all=20
> together outside=20
> >>>> of a doxygen documentation block. Otherwise the=20
> functions will be=20
> >>>> included in the documentation, or have each to be surrounded by=20
> >>>> end/start tags for documentation blocks.
> >>>
> >>> Can you explain this in detail please?
> >>> What do you mean 'outside of a doxygen documentation block'?
> >>
> >>
> >> A doxygen documentation block starts with
> >>
> >>  	/*@{*/
> >>
> >> and ends with
> >>
> >>  	/*}@*/
> >>
> >>
> >> However, I was wrong with the above statement.
> >>
> >> If the function does NOT contain any
> >>
> >>  	/** or /*!
> >>
> >> comments, then it will NOT be part of the documentation.
> >>
> >> Thus static and non API functions should ONLY use /* comments.
> >>
> >> I just corrected the doxygen template c file at=20
> >> http://www.tbi.univie.ac.at/~raim/odeSolver/data/doxygenComments.c
> >>
> >> Rainer
> >>
> >>
> >>>
> >>>> -----Original Message-----
> >>>> From: Rainer Machne [mailto:ra...@tb...]
> >>>> Sent: 19 April 2006 14:48
> >>>> To: Andrew Finney
> >>>> Cc: SOSlib Development
> >>>> Subject: RE: [SOSlib-devel] RE: comment on proposed exact event=20
> >>>> implementation[Scanned]
> >>>>
> >>>> 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=20
> functions, if=20
> >>>> they are defined before the are used.
> >>>>
> >>>> Would people support a convention that we still declare such=20
> >>>> private functions in the header of the c file, in which
> >> they are used?
> >>>>
> >>>> This would also allow to put private functions all=20
> together outside=20
> >>>> of a doxygen documentation block. Otherwise the=20
> functions will be=20
> >>>> included in the documentation, or have each to be surrounded by=20
> >>>> 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=20
> exact event=20
> >>>>>> 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=20
> >>>>>> 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=20
> checks only for=20
> >>>>>> 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=20
> ago, while=20
> >>>>>> 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=20
> 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
> >>>>>> applications which
> >>>>>>>> knew what type of solver is required (currently ODEs or no
> >>>>>> ODEs, but
> >>>>>>>> eventually also DAEs or even stochastic solvers) can=20
> use these=20
> >>>>>>>> `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=20
> >>>>>>>> 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] =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
> >>>>>> 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
> >>>>>>>>>>>>>> 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=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=20
> 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
> >>>>>> were 0 before.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> This should do it, right?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> In the current version it is wrong:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> It's the line 636 in integratorInstance
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>   if ( data->trigger[i] =3D=3D 0 &&
> >>>>>> evaluateAST(trigger, data) )
> >>>>>>>>>>>>>>>>     fired++; (leading to assignment execution in
> >>>>>>>> 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=20
> only detects
> >>>>>>>>>>>> transitions
> >>>>>>>>>>>>>>>>> because x < 10 maps to x - 10 =3D=3D 0.  The=20
> root is only
> >>>>>>>>>>>> true at the
> >>>>>>>>>>>>>>>>> transition not at all points x < 10.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> I think we need to be very careful about=20
> 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=20
> 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=20
> 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
> >>>>>> 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=20
> conditions also
> >>>>>>>>>>>>>> becomes true
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> This can become tricky. As far as I
> >> understood the root
> >>>>>>>>>>>>>> finder, it
> >>>>>>>>>>>>>>>>>> stops integrating at the time where it found
> >> the root.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Thus we might have to include a code
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> if ( triggerWasTrue )
> >>>>>>>>>>>>>>>>>>   rootFunction =3D 1.0;
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> to supress root finding for triggers that are
> >>>>>> already true.
> >>>>>>>>>>>>>>>>>> The same should probably be done for combined
> >>>>>>>>>>>> triggers, for the
> >>>>>>>>>>>>>>>>>> expression that becomes true first and needs
> >>>> to wait for
> >>>>>>>>>>>>>> the second
> >>>>>>>>>>>>>>>>>> (or all) other inequalities of the trigger.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Rainer
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> yours Andrew
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>>>>>>>>>> From: Rainer Machne=20
> [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
> >>>>>>>>>>>>>>>>>> =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
> >>>>>> beyond the
> >>>>>>>>>>>>>>>>>> threshold
> >>>>>>>>>>>>>>>>>>>> (10) must wait for the second (b) to also move
> >>>>>>>>>>>> beyond its own
> >>>>>>>>>>>>>>>>>>>> threshold. I.e. for such event=20
> 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=20
> expression, but can
> >>>>>>>>>>>> be a logic
> >>>>>>>>>>>>>>>>>>>> combination of different boolean=20
> 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
> >>>>>> expressions 10 - a
> >>>>>>>>>>>>>>>>>>>> =3D=3D 0 and b -
> >>>>>>>>>>>>>>>>>>>>>> 10 =3D=3D 0
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> when you find a root you re-evaluate=20
> the complete
> >>>>>>>>>>>>>>>>>> triggers to see
> >>>>>>>>>>>>>>>>>>>>>> what's really fired.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> or is there a better approach?
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Are there other forms of events, where this
> >>>>>> method can
> >>>>>>>>>>>>>>>>>>>> not be applied?
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Well there is equality e.g. x =3D=3D 40 I think
> >>>>>> that should
> >>>>>>>>>>>>>>>>>> work as x -
> >>>>>>>>>>>>>>>>>>>>>> 40 =3D=3D 0 Inequality is fine to you map x
> >> !=3D 40 to x
> >>>>>>>>>>>> - 40 =3D=3D 0
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> In both cases you need to revaluate the trigger
> >>>>>>>>>>>>>> expression but
> >>>>>>>>>>>>>>>>>>>>>> probably with an epsilon (especially
> >>>> equality) or you
> >>>>>>>>>>>>>>>>>> may have to
> >>>>>>>>>>>>>>>>>>>>>> force a value from 39.9999 to 40 after the root
> >>>>>>>>>>>>>>>> finding process.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> One thing to very careful of is time dependant
> >>>>>>>>>>>>>>>> expressions (ones
> >>>>>>>>>>>>>>>>>>>>>> containing the csymbol for time) not so
> >> much in the
> >>>>>>>>>>>>>>>> triggers but
> >>>>>>>>>>>>>>>>>>>>>> make sure time is set right when you roll
> >>>>>>>>>>>>>> integration back or
> >>>>>>>>>>>>>>>>>>>>>> forward...hopefully that's obvious.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> yours Andrew
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>>>>>>>>>>>>> From: Rainer Machne
> >> [mailto:ra...@tb...]
> >>>>>>>>>>>>>>>>>>>>>>> Sent: 12 April 2006 14:40
> >>>>>>>>>>>>>>>>>>>>>>> To: Christoph Flamm
> >>>>>>>>>>>>>>>>>>>>>>> Cc: Andrew Finney
> >>>>>>>>>>>>>>>>>>>>>>> Subject: Re: comment on proposed exact event=20
> >>>>>>>>>>>>>>>>>>>>>>> implementation[Scanned]
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Hi Andrew and Xtof
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> another question:
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Currently we tell the root function to
> >>>> evaluate the
> >>>>>>>>>>>>>> expression
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> leftChildofTrigger - rightChildOfTrigger
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> for which the root finder tries to find a
> >>>> root, i.e.
> >>>>>>>>>>>>>>>>>>>> time points
> >>>>>>>>>>>>>>>>>>>>>>> where this expression evaluates to 0.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> This is valid for event like
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> if x > 40
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> where the method will try find a time
> >> point where
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> x - 40 =3D=3D 0.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Is this generally valid? Are there
> >> other forms of
> >>>>>>>>>>>>>>>> events, where
> >>>>>>>>>>>>>>>>>>>>>>> this method can not be applied?
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Rainer
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> On Wed, 12 Apr 2006, Christoph Flamm wrote:
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> hi andrew,
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> yes, you are right root finding is the
> >>>> only proper
> >>>>>>>>>>>>>>>>>>>> way to detect
> >>>>>>>>>>>>>>>>>>>>>>>> events accurately. also the code we need
> >>>>>> to implement
> >>>>>>>>>>>>>>>>>>>> would be
> >>>>>>>>>>>>>>>>>>>>>>>> much simpler with root finding. the
> >> down side of
> >>>>>>>>>>>>>>>> this approach
> >>>>>>>>>>>>>>>>>>>>>>> is, that the
> >>>>>>>>>>>>>>>>>>>>>>>> integration with root finding turned on
> >>>> drastically
> >>>>>>>>>>>>>>>>>>>> slowes down
> >>>>>>>>>>>>>>>>>>>>>>>> the integration speed especially if we
> >>>>>> have a lot of
> >>>>>>>>>>>>>>>> triggers!
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> the other problem which we did not touch
> >>>> during the
> >>>>>>>>>>>>>>>>>>>>>>> hackathon is what
> >>>>>>>>>>>>>>>>>>>>>>>> happens if to events trigger exactely at the
> >>>>>>>>>>>> same time but
> >>>>>>>>>>>>>>>>>>>>>>>> influence each other.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> suppose the following two events:
> >>>>>>>>>>>>>>>>>>>>>>>> (1) if x > 20 then diminish the concentration
> >>>>>>>>>> of y to 10
> >>>>>>>>>>>>>>>>>>>>>>>> (2) if y > 20 then diminish the concentration
> >>>>>>>>>> of x to 10
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> this is something like a cyclic
> >> dependency of the
> >>>>>>>>>>>>>>>>>> events. if both
> >>>>>>>>>>>>>>>>>>>>>>>> events are triggered at the same time, which
> >>>>>>>>>>>>>>>>>>>> could happen,
> >>>>>>>>>>>>>>>>>>>>>>> what shall
> >>>>>>>>>>>>>>>>>>>>>>>> we do?  which ever event we execute first
> >>>>>>>>>> invalidates the
> >>>>>>>>>>>>>>>>>>>>>>> trigger for
> >>>>>>>>>>>>>>>>>>>>>>>> the second one.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> in such a case an priority ordering of the
> >>>>>>>>>>>> events is needed
> >>>>>>>>>>>>>>>>>>>>>>> to resolve
> >>>>>>>>>>>>>>>>>>>>>>>> the problem right? is an answer to
> >> something like
> >>>>>>>>>>>>>> that in the
> >>>>>>>>>>>>>>>>>>>>>>>> SBML specs?
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> i think that the method i suggested at
> >>>> the hackaton
> >>>>>>>>>>>>>>>>>>>> would give
> >>>>>>>>>>>>>>>>>>>>>>>> us a good balance between speed and
> >> "accuracy of
> >>>>>>>>>>>> the event
> >>>>>>>>>>>>>>>>>>>>>>> detection" (but
> >>>>>>>>>>>>>>>>>>>>>>>> the coding is more difficult!)
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> rainer suggested as an alternative=20
> 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=20
> 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
> >>>>>>>
> >>>>>>
> >>>>
> >>=20
> http://sel.as-us.falkag.net/sel?cmd__________________________________
> >>>>>> _
> >>>>>>> ____________
> >>>>>>> sbmlsolver-devel mailing list
> >>>>>>> sbm...@li...
> >>>>>>> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
>=20

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

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

Andrew

> Mutually recursive functions require forward declarations e.g.:

Of course. Thanks!


> if a forward declaration is required or if we decide we must have
> private prototypes
> (my preference no!)
> then the private prototypes go in the relevant C file at the top of the
> file

Can you explain why you don't like this? Is this a general style question
or can there be any problems with the redundant declarations?

As said, I like to have all existing functions listed somewhere to keep 
the overview.

But if this is not necessary/considered unstylish/problematic in general, 
then I'll happily agree that redundancies are bad - well, at least in 
code :-) .

Rainer


On Wed, 19 Apr 2006, Andrew Finney wrote:

> Rainer
>
> you wrote:
>
>> Can't you always just write the function before it is used?
>> Does this also
>> work for recursive functions? Sorry for my illiteracy with such basic
>> stuff :-)
>
> Mutually recursive functions require forward declarations e.g.:
>
> void f();
>
> void g()
> {
>  f();
> }
>
> void f()
> {
>  g();
> }
>
>>> d) any other case is public!
>>
>> I.e. either in ...internal.h or in API .h files, right?
>
> if a forward declaration is required or if we decide we must have
> private prototypes
> (my preference no!)
> then the private prototypes go in the relevant C file at the top of the
> file
>
> otherwise
>
> if the function is private to the library it goes in XXX_internal.h
>
> otherwise
>
> the function must be public/API so it goes in XXX.h
>
> OK?
>
> yours Andrew
>
>> -----Original Message-----
>> From: Rainer Machne [mailto:ra...@tb...]
>> Sent: 19 April 2006 15:25
>> To: Andrew Finney
>> Cc: SOSlib Development
>> Subject: RE: [SOSlib-devel] RE: comment on proposed exact
>> event implementation[Scanned]
>>
>> Andrew
>>
>> On Wed, 19 Apr 2006, Andrew Finney wrote:
>>>> Would people support a convention that we still declare
>> such private
>>>> functions in the header of the c file, in which they are used?
>>>>
>>>
>>> Hmmm
>>>
>>> Do you mean the .h file or the top section of the .c file?
>>
>> I meant the top section of the .c file.
>>
>>>
>>> my preference is for
>>>
>>> a) no redundant prototypes (simple is best) i.e. only used where a
>>> forward declaration is needed
>>
>> Personally, I like to have nice lists of all existing functions, i.e.
>> header files (.h) plus declarations at the top section of .c
>> files for static functions. It just makes it easier for me to
>> recall the exact order of function calls, without parsing
>> throught the source.
>>
>> However, as it is not necessary for doxygen, we could remove
>> all declarations of static functions in .c file, if people wish so.
>>
>>
>>> b) if they are necessary they go in the .c file as a first resort
>>
>> I can't think of a case where this would be necessary, if the
>> function is
>> only used within this .c file.
>>
>> Can't you always just write the function before it is used?
>> Does this also
>> work for recursive functions? Sorry for my illiteracy with such basic
>> stuff :-)
>>
>>
>>> c) if they are required to be in a header but they are not
>> part of the
>>> API
>>>    they should go in a header like:  intergatorInstance_internal.h
>>>   In the long term we ought to separate the API prototypes from the
>>>   internal prototypes in two separate sets of headers so that
>>> applications
>>>   can clearly see what is the API.
>>
>> Agree.
>>
>>
>>> d) any other case is public!
>>
>> I.e. either in ...internal.h or in API .h files, right?
>>
>>> e) don't use SBML_ODESOLVER_API unless the function is strictly part
>>> of the API (I'm guilty too)
>>
>> Agree.
>>
>>
>>>
>>>> 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.
>>>
>>> Can you explain this in detail please?
>>> What do you mean 'outside of a doxygen documentation block'?
>>
>>
>> A doxygen documentation block starts with
>>
>>  	/*@{*/
>>
>> and ends with
>>
>>  	/*}@*/
>>
>>
>> However, I was wrong with the above statement.
>>
>> If the function does NOT contain any
>>
>>  	/** or /*!
>>
>> comments, then it will NOT be part of the documentation.
>>
>> Thus static and non API functions should ONLY use /* comments.
>>
>> I just corrected the doxygen template c file at
>> http://www.tbi.univie.ac.at/~raim/odeSolver/data/doxygenComments.c
>>
>> Rainer
>>
>>
>>>
>>>> -----Original Message-----
>>>> From: Rainer Machne [mailto:ra...@tb...]
>>>> Sent: 19 April 2006 14:48
>>>> To: Andrew Finney
>>>> Cc: SOSlib Development
>>>> Subject: RE: [SOSlib-devel] RE: comment on proposed exact
>>>> event implementation[Scanned]
>>>>
>>>> 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
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

RE: [SOSlib-devel] simple event handling corrected[Scanned]

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

> I think a simpler API is easier to maintain.

I agree.

The mess with Eryk's design point functions came up, because I was 
creating (too?) many API functions for all kinds of stuff (covdeSettings, 
cvodeResults, sbmlResults, integratorInstance), instead of keeping it 
simple and correct.



Another reason for having the simple integratorOneStep function which only
switches between solvers, was to make a future incorporation of other 
solvers as easy as possible and to keep the number of functions that need 
to know about the specific solver as small as possible.

In the .c file, they are all collected under the comment

/**************** functions that switch between solvers *****************/


Anyways, the OneStepWithoutEventProcessing jsut adds one more functions so 
this is OK.

But, I still wonder about the use of this function.

It could also be done e.g. by a function

 	IntegratorInstance_processEvents(ii, BOOLEAN),

that could be called between OneStep calls.

Rainer





On Wed, 19 Apr 2006, Andrew Finney wrote:

> Rainer
>
> I think a simpler API is easier to maintain.
>
> yours Andrew
>
>> -----Original Message-----
>> From: Rainer Machne [mailto:ra...@tb...]
>> Sent: 19 April 2006 15:35
>> To: Andrew Finney
>> Cc: SOSlib Development
>> Subject: RE: [SOSlib-devel] simple event handling corrected[Scanned]
>>
>>
>> On Wed, 19 Apr 2006, Andrew Finney wrote:
>>
>>>
>>>> * remove redundant function II_checkTrigger or alternatively
>>>> * provide this function as API -- maybe without the event
>> execution ??
>>>>
>>>>
>>>
>>> if it aint called get rid of it
>>
>> Ok, I agree.
>>
>> I just thought that, if the function
>>
>> IntegratorInstance_integrateOneStepWithoutEventProcessing
>>
>> is part of the API, people might still be interested in a
>> simple external checking for number of events.
>>
>> Besides the confusion about it's declaration, the question
>> whether you wanted this function part of the API was
>> regarding this function.
>>
>> What use do you imagine for this function? Is it just for testing?
>>
>>
>>
>>
>>>> * decide on whether or not to have API functions for solverOneStep
>>>> (for each solver, no ODES, CVODES, IDA, etc.) or if this should be
>>>> handled inside the library and integrateOneStep will be
>> the only API
>>>> one step function
>>>>
>>>
>>> my preference is to have only one API one step function
>>
>> Ok, I guess the few if statments in the integrateOneStep will
>> not be really a performance drawback.
>>
>> Initially, I made the cvodeOneStep and simpleOneStep
>> functions public (part of the API) to enable the most direct
>> use of a specific solver for applications that know what type
>> of model they have.
>>
>> It would be easy but is not possible anymore with the
>>
>>  	engine->processEvents
>>
>> option, set within above discussed function, unless we add
>>
>> cvodeOneStepWithoutEventProcessing
>> simpleOneStepWithoutEventProcessing
>>
>> and eventually
>>
>> idaOneStepWithoutEventProcessing
>>
>> and others.
>>
>> The integratorOneStep was thought to be a simple wrapper for
>> applications that don't know there model types.
>>
>> Rainer
>>
>>
>>
>>
>>>> -----Original Message-----
>>>> From: sbm...@li...
>>>> [mailto:sbm...@li...] On Behalf Of
>>>> Rainer Machne
>>>> Sent: 19 April 2006 14:56
>>>> To: SOSlib Development
>>>> Subject: [SOSlib-devel] simple event handling corrected[Scanned]
>>>>
>>>> Hi All
>>>>
>>>> Just wanted to let you know, that I have submitted a
>>>> (hopefully) corrected version of the simple event handling.
>>>>
>>>> TODOs found:
>>>>
>>>> * clean up the use of the SBML_ODESOLVER_API tag (part of C++ API
>>>> todo)
>>>>
>>>> * decide wheter private functions should be declared at
>> the header of
>>>> the c file
>>>>
>>>> * remove redundant function II_checkTrigger or alternatively
>>>> * provide this function as API -- maybe without the event
>> execution ??
>>>>
>>>>
>>>> * decide on whether or not to have API functions for solverOneStep
>>>> (for each solver, no ODES, CVODES, IDA, etc.) or if this should be
>>>> handled inside the library and integrateOneStep will be
>> the only API
>>>> one step function
>>>>
>>>> Rainer
>>>>
>>>>
>>>>
>>>>
>>>> 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 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
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> 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=lnk&kid=120709&bid=263057&
>>>> dat=121642
>>>> _______________________________________________
>>>> sbmlsolver-devel mailing list
>>>> sbm...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>>>>
>>>
>>
>
>
> -------------------------------------------------------
> 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
>

RE: [SOSlib-devel] simple event handling corrected[Scanned]

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

Rainer

I think a simpler API is easier to maintain.

yours Andrew=20

> -----Original Message-----
> From: Rainer Machne [mailto:ra...@tb...]=20
> Sent: 19 April 2006 15:35
> To: Andrew Finney
> Cc: SOSlib Development
> Subject: RE: [SOSlib-devel] simple event handling corrected[Scanned]
>=20
>=20
> On Wed, 19 Apr 2006, Andrew Finney wrote:
>=20
> >
> >> * remove redundant function II_checkTrigger or alternatively
> >> * provide this function as API -- maybe without the event=20
> execution ??
> >>
> >>
> >
> > if it aint called get rid of it
>=20
> Ok, I agree.
>=20
> I just thought that, if the function
>=20
> IntegratorInstance_integrateOneStepWithoutEventProcessing
>=20
> is part of the API, people might still be interested in a=20
> simple external checking for number of events.
>=20
> Besides the confusion about it's declaration, the question=20
> whether you wanted this function part of the API was=20
> regarding this function.
>=20
> What use do you imagine for this function? Is it just for testing?
>=20
>=20
>=20
>=20
> >> * decide on whether or not to have API functions for solverOneStep=20
> >> (for each solver, no ODES, CVODES, IDA, etc.) or if this should be=20
> >> handled inside the library and integrateOneStep will be=20
> the only API=20
> >> one step function
> >>
> >
> > my preference is to have only one API one step function
>=20
> Ok, I guess the few if statments in the integrateOneStep will=20
> not be really a performance drawback.
>=20
> Initially, I made the cvodeOneStep and simpleOneStep=20
> functions public (part of the API) to enable the most direct=20
> use of a specific solver for applications that know what type=20
> of model they have.
>=20
> It would be easy but is not possible anymore with the
>=20
>  	engine->processEvents
>=20
> option, set within above discussed function, unless we add
>=20
> cvodeOneStepWithoutEventProcessing
> simpleOneStepWithoutEventProcessing
>=20
> and eventually
>=20
> idaOneStepWithoutEventProcessing
>=20
> and others.
>=20
> The integratorOneStep was thought to be a simple wrapper for=20
> applications that don't know there model types.
>=20
> Rainer
>=20
>=20
>=20
>=20
> >> -----Original Message-----
> >> From: sbm...@li...
> >> [mailto:sbm...@li...] On Behalf Of=20
> >> Rainer Machne
> >> Sent: 19 April 2006 14:56
> >> To: SOSlib Development
> >> Subject: [SOSlib-devel] simple event handling corrected[Scanned]
> >>
> >> Hi All
> >>
> >> Just wanted to let you know, that I have submitted a
> >> (hopefully) corrected version of the simple event handling.
> >>
> >> TODOs found:
> >>
> >> * clean up the use of the SBML_ODESOLVER_API tag (part of C++ API=20
> >> todo)
> >>
> >> * decide wheter private functions should be declared at=20
> the header of=20
> >> the c file
> >>
> >> * remove redundant function II_checkTrigger or alternatively
> >> * provide this function as API -- maybe without the event=20
> execution ??
> >>
> >>
> >> * decide on whether or not to have API functions for solverOneStep=20
> >> (for each solver, no ODES, CVODES, IDA, etc.) or if this should be=20
> >> handled inside the library and integrateOneStep will be=20
> the only API=20
> >> one step function
> >>
> >> Rainer
> >>
> >>
> >>
> >>
> >> On Wed, 19 Apr 2006, Andrew Finney wrote:
> >>
> >>> Rainer
> >>>
> >>> IntegratorInstance_processEventsAndAssignments
> >>>
> >>> doesn't have a declaration: its not required as its not=20
> part of the=20
> >>> API the SBML_ODESOLVER_API qualification is redundant - I
> >> guess that
> >>> confused you That's my fault.  Remind me to update the=20
> dynalically=20
> >>> 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=20
> >>>> 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=20
> >>>> 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=20
> only for=20
> >>>> 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=20
> >>>> 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=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
> >>>> 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=20
> >>>>>> `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=20
> >>>>>> 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] =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=20
> 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=20
> incorrectly but
> >>>>>>>>>> I'll work
> >>>>>>>>>>>>> around it perhaps we'll need yet another option.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> The current implementation
> >>>>>>>>>>>>
> >>>>>>>>>>>>>   if ( data->trigger[i] =3D=3D 0 &&
> >> evaluateAST(trigger, data) )
> >>>>>>>>>>>>>     fired++; (leading to assignment execution in
> >>>> calling code)
> >>>>>>>>>>>>>     data->trigger[i] =3D 1;
> >>>>>>>>>>>>>   else
> >>>>>>>>>>>>>     data->trigger[i] =3D 0;
> >>>>>>>>>>>>
> >>>>>>>>>>>> means that event triggers are set to 0, whenever they
> >>>>>>>> have already
> >>>>>>>>>>>> been fired, even when the trigger is still true.
> >>>>>>>>>>>>
> >>>>>>>>>>>> That means that events are again executed in the=20
> time step=20
> >>>>>>>>>>>> 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=20
> 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=20
> 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,=20
> 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
> >>>> were 0 before.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> This should do it, right?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> In the current version it is wrong:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> It's the line 636 in integratorInstance
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>   if ( data->trigger[i] =3D=3D 0 &&
> >>>> evaluateAST(trigger, data) )
> >>>>>>>>>>>>>>     fired++; (leading to assignment execution in
> >>>>>> 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=20
> 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=20
> understood the root
> >>>>>>>>>>>> finder, it
> >>>>>>>>>>>>>>>> stops integrating at the time where it found=20
> 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=20
> means you
> >>>>>>>>>>>> potentially
> >>>>>>>>>>>>>>> miss a transition.  Having written that I=20
> 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=20
> 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=20
> guess it could
> >>>>>>>>>>>> be a very
> >>>>>>>>>>>>>>> small fraction of the time step length.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>    Perhaps this should be a constant set by=20
> 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=20
> 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=20
> 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=20
> 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
> >>>> 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=20
> understood the root
> >>>>>>>>>>>> finder, it
> >>>>>>>>>>>>>>>> stops integrating at the time where it found=20
> the root.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Thus we might have to include a code
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> if ( triggerWasTrue )
> >>>>>>>>>>>>>>>>   rootFunction =3D 1.0;
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> to supress root finding for triggers that are
> >>>> already true.
> >>>>>>>>>>>>>>>> The same should probably be done for combined
> >>>>>>>>>> triggers, for the
> >>>>>>>>>>>>>>>> expression that becomes true first and needs
> >> to wait for
> >>>>>>>>>>>> the second
> >>>>>>>>>>>>>>>> (or all) other inequalities of the trigger.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Rainer
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> yours Andrew
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>>>>>>>> From: Rainer Machne [mailto:ra...@tb...]
> >>>>>>>>>>>>>>>>>> Sent: 12 April 2006 15:21
> >>>>>>>>>>>>>>>>>> To: Christoph Flamm
> >>>>>>>>>>>>>>>>>> Cc: Andrew Finney
> >>>>>>>>>>>>>>>>>> Subject: RE: comment on proposed exact event
> >>>>>>>>>>>>>>>> implementation[Scanned]
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Hi Xtof,
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On Wed, 12 Apr 2006, Christoph Flamm wrote:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> hi andrew,
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> am i getting that right, in essence the recipe
> >>>>>> 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
> >>>>>>>>>>>>>>>> =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
> >>>> 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=20
> expression
> >>>>>>>>>>>>>>>>>> separating out
> >>>>>>>>>>>>>>>>>>>> all the inequalities
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> e.g. a < 10 && b > 10 becomes 2 root
> >>>> expressions 10 - a
> >>>>>>>>>>>>>>>>>> =3D=3D 0 and b -
> >>>>>>>>>>>>>>>>>>>> 10 =3D=3D 0
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> when you find a root you re-evaluate the complete
> >>>>>>>>>>>>>>>> triggers to see
> >>>>>>>>>>>>>>>>>>>> what's really fired.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> or is there a better approach?
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Are there other forms of events, where this
> >>>> method can
> >>>>>>>>>>>>>>>>>> not be applied?
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Well there is equality e.g. x =3D=3D 40 I think
> >>>> that should
> >>>>>>>>>>>>>>>> work as x -
> >>>>>>>>>>>>>>>>>>>> 40 =3D=3D 0 Inequality is fine to you map x=20
> !=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=20
> 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=20
> [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=20
> point where
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> x - 40 =3D=3D 0.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Is this generally valid? Are there=20
> 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=20
> 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=20
> 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=20
> 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=20
> "accuracy of
> >>>>>>>>>> the event
> >>>>>>>>>>>>>>>>>>>>> detection" (but
> >>>>>>>>>>>>>>>>>>>>>> the coding is more difficult!)
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> rainer suggested as an alternative to=20
> the mixed=20
> >>>>>>>>>>>>>>>>>>>>>> root-finding/non-root-finding strategy
> >> to make the
> >>>>>>>>>>>>>>>>>> integration
> >>>>>>>>>>>>>>>>>>>>>> step smaller until the exact time of=20
> 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
> >>>> services, security?
> >>>>> Get stuff done quickly with pre-integrated technology to
> >>>> make your job
> >>>>> easier Download IBM WebSphere Application Server=20
> v.1.0.1 based on=20
> >>>>> Apache Geronimo
> >>>>>
> >>>>
> >>=20
> http://sel.as-us.falkag.net/sel?cmd__________________________________
> >>>> _
> >>>>> ____________
> >>>>> sbmlsolver-devel mailing list
> >>>>> sbm...@li...
> >>>>> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
> >>>>>
> >>>>
> >>>
> >>
> >>
> >> -------------------------------------------------------
> >> Using Tomcat but need to do more? Need to support web services,=20
> >> security?
> >> Get stuff done quickly with pre-integrated technology to make your=20
> >> job easier Download IBM WebSphere Application Server
> >> v.1.0.1 based on Apache Geronimo
> >> =
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&
> >> dat=3D121642
> >> _______________________________________________
> >> sbmlsolver-devel mailing list
> >> sbm...@li...
> >> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
> >>
> >
>=20

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

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

Rainer

you wrote:

> Can't you always just write the function before it is used?=20
> Does this also=20
> work for recursive functions? Sorry for my illiteracy with such basic=20
> stuff :-)

Mutually recursive functions require forward declarations e.g.:

void f();

void g()
{
  f();
}

void f()
{
  g();
} =20

> > d) any other case is public!
>=20
> I.e. either in ...internal.h or in API .h files, right?

if a forward declaration is required or if we decide we must have
private prototypes
(my preference no!)
then the private prototypes go in the relevant C file at the top of the
file

otherwise

if the function is private to the library it goes in XXX_internal.h

otherwise

the function must be public/API so it goes in XXX.h

OK?

yours Andrew

> -----Original Message-----
> From: Rainer Machne [mailto:ra...@tb...]=20
> Sent: 19 April 2006 15:25
> To: Andrew Finney
> Cc: SOSlib Development
> Subject: RE: [SOSlib-devel] RE: comment on proposed exact=20
> event implementation[Scanned]
>=20
> Andrew
>=20
> On Wed, 19 Apr 2006, Andrew Finney wrote:
> >> Would people support a convention that we still declare=20
> such private=20
> >> functions in the header of the c file, in which they are used?
> >>
> >
> > Hmmm
> >
> > Do you mean the .h file or the top section of the .c file?
>=20
> I meant the top section of the .c file.
>=20
> >
> > my preference is for
> >
> > a) no redundant prototypes (simple is best) i.e. only used where a=20
> > forward declaration is needed
>=20
> Personally, I like to have nice lists of all existing functions, i.e.=20
> header files (.h) plus declarations at the top section of .c=20
> files for static functions. It just makes it easier for me to=20
> recall the exact order of function calls, without parsing=20
> throught the source.
>=20
> However, as it is not necessary for doxygen, we could remove=20
> all declarations of static functions in .c file, if people wish so.
>=20
>=20
> > b) if they are necessary they go in the .c file as a first resort
>=20
> I can't think of a case where this would be necessary, if the=20
> function is=20
> only used within this .c file.
>=20
> Can't you always just write the function before it is used?=20
> Does this also=20
> work for recursive functions? Sorry for my illiteracy with such basic=20
> stuff :-)
>=20
>=20
> > c) if they are required to be in a header but they are not=20
> part of the
> > API
> >    they should go in a header like:  intergatorInstance_internal.h
> >   In the long term we ought to separate the API prototypes from the
> >   internal prototypes in two separate sets of headers so that
> > applications
> >   can clearly see what is the API.
>=20
> Agree.
>=20
>=20
> > d) any other case is public!
>=20
> I.e. either in ...internal.h or in API .h files, right?
>=20
> > e) don't use SBML_ODESOLVER_API unless the function is strictly part
> > of the API (I'm guilty too)
>=20
> Agree.
>=20
>=20
> >
> >> 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.
> >
> > Can you explain this in detail please?
> > What do you mean 'outside of a doxygen documentation block'?
>=20
>=20
> A doxygen documentation block starts with
>=20
>  	/*@{*/
>=20
> and ends with
>=20
>  	/*}@*/
>=20
>=20
> However, I was wrong with the above statement.
>=20
> If the function does NOT contain any
>=20
>  	/** or /*!
>=20
> comments, then it will NOT be part of the documentation.
>=20
> Thus static and non API functions should ONLY use /* comments.
>=20
> I just corrected the doxygen template c file at
> http://www.tbi.univie.ac.at/~raim/odeSolver/data/doxygenComments.c
>=20
> Rainer
>=20
>=20
> >
> >> -----Original Message-----
> >> From: Rainer Machne [mailto:ra...@tb...]
> >> Sent: 19 April 2006 14:48
> >> To: Andrew Finney
> >> Cc: SOSlib Development
> >> Subject: RE: [SOSlib-devel] RE: comment on proposed exact
> >> event implementation[Scanned]
> >>
> >> Andrew
> >>
> >> On Wed, 19 Apr 2006, Andrew Finney wrote:
> >>
> >>> Rainer
> >>>
> >>> IntegratorInstance_processEventsAndAssignments
> >>>
> >>> doesn't have a declaration: its not required as its not=20
> 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=20
> 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] =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=20
> 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=20
> incorrectly but
> >>>>>>>>>> I'll work
> >>>>>>>>>>>>> around it perhaps we'll need yet another option.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> The current implementation
> >>>>>>>>>>>>
> >>>>>>>>>>>>>   if ( data->trigger[i] =3D=3D 0 &&
> >> evaluateAST(trigger, data) )
> >>>>>>>>>>>>>     fired++; (leading to assignment execution in
> >>>> calling code)
> >>>>>>>>>>>>>     data->trigger[i] =3D 1;
> >>>>>>>>>>>>>   else
> >>>>>>>>>>>>>     data->trigger[i] =3D 0;
> >>>>>>>>>>>>
> >>>>>>>>>>>> means that event triggers are set to 0, whenever they
> >>>>>>>> have already
> >>>>>>>>>>>> been fired, even when the trigger is still true.
> >>>>>>>>>>>>
> >>>>>>>>>>>> That means that events are again executed in the=20
> 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=20
> 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=20
> 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,=20
> 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
> >>>> were 0 before.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> This should do it, right?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> In the current version it is wrong:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> It's the line 636 in integratorInstance
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>   if ( data->trigger[i] =3D=3D 0 &&
> >>>> evaluateAST(trigger, data) )
> >>>>>>>>>>>>>>     fired++; (leading to assignment execution in
> >>>>>> 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=20
> 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=20
> understood the root
> >>>>>>>>>>>> finder, it
> >>>>>>>>>>>>>>>> stops integrating at the time where it found=20
> 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=20
> means you
> >>>>>>>>>>>> potentially
> >>>>>>>>>>>>>>> miss a transition.  Having written that I=20
> 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=20
> 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=20
> guess it could
> >>>>>>>>>>>> be a very
> >>>>>>>>>>>>>>> small fraction of the time step length.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>    Perhaps this should be a constant set by=20
> 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=20
> 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=20
> 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=20
> 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
> >>>> 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=20
> understood the root
> >>>>>>>>>>>> finder, it
> >>>>>>>>>>>>>>>> stops integrating at the time where it found=20
> the root.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Thus we might have to include a code
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> if ( triggerWasTrue )
> >>>>>>>>>>>>>>>>   rootFunction =3D 1.0;
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> to supress root finding for triggers that are
> >>>> already true.
> >>>>>>>>>>>>>>>> The same should probably be done for combined
> >>>>>>>>>> triggers, for the
> >>>>>>>>>>>>>>>> expression that becomes true first and needs
> >> to wait for
> >>>>>>>>>>>> the second
> >>>>>>>>>>>>>>>> (or all) other inequalities of the trigger.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Rainer
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> yours Andrew
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>>>>>>>> From: Rainer Machne [mailto:ra...@tb...]
> >>>>>>>>>>>>>>>>>> Sent: 12 April 2006 15:21
> >>>>>>>>>>>>>>>>>> To: Christoph Flamm
> >>>>>>>>>>>>>>>>>> Cc: Andrew Finney
> >>>>>>>>>>>>>>>>>> Subject: RE: comment on proposed exact event
> >>>>>>>>>>>>>>>> implementation[Scanned]
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Hi Xtof,
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On Wed, 12 Apr 2006, Christoph Flamm wrote:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> hi andrew,
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> am i getting that right, in essence the recipe
> >>>>>> 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
> >>>>>>>>>>>>>>>> =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
> >>>> 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=20
> expression
> >>>>>>>>>>>>>>>>>> separating out
> >>>>>>>>>>>>>>>>>>>> all the inequalities
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> e.g. a < 10 && b > 10 becomes 2 root
> >>>> expressions 10 - a
> >>>>>>>>>>>>>>>>>> =3D=3D 0 and b -
> >>>>>>>>>>>>>>>>>>>> 10 =3D=3D 0
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> when you find a root you re-evaluate the complete
> >>>>>>>>>>>>>>>> triggers to see
> >>>>>>>>>>>>>>>>>>>> what's really fired.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> or is there a better approach?
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Are there other forms of events, where this
> >>>> method can
> >>>>>>>>>>>>>>>>>> not be applied?
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Well there is equality e.g. x =3D=3D 40 I think
> >>>> that should
> >>>>>>>>>>>>>>>> work as x -
> >>>>>>>>>>>>>>>>>>>> 40 =3D=3D 0 Inequality is fine to you map x=20
> !=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=20
> 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=20
> [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=20
> point where
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> x - 40 =3D=3D 0.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Is this generally valid? Are there=20
> 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=20
> 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=20
> 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=20
> 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=20
> "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=20
> 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
> >>>> services, security?
> >>>>> Get stuff done quickly with pre-integrated technology to
> >>>> make your job
> >>>>> easier Download IBM WebSphere Application Server=20
> v.1.0.1 based on
> >>>>> Apache Geronimo
> >>>>>
> >>>>
> >>=20
> http://sel.as-us.falkag.net/sel?cmd__________________________________
> >>>> _
> >>>>> ____________
> >>>>> sbmlsolver-devel mailing list
> >>>>> sbm...@li...
> >>>>> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
> >>>>>
> >>>>
> >>>
> >>
> >
>=20

RE: [SOSlib-devel] simple event handling corrected[Scanned]

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

On Wed, 19 Apr 2006, Andrew Finney wrote:

>
>> * remove redundant function II_checkTrigger or alternatively
>> * provide this function as API -- maybe without the event execution ??
>>
>>
>
> if it aint called get rid of it

Ok, I agree.

I just thought that, if the function

IntegratorInstance_integrateOneStepWithoutEventProcessing

is part of the API, people might still be interested in a simple external 
checking for number of events.

Besides the confusion about it's declaration, the question whether you 
wanted this function part of the API was regarding this function.

What use do you imagine for this function? Is it just for testing?




>> * decide on whether or not to have API functions for
>> solverOneStep (for each solver, no ODES, CVODES, IDA, etc.)
>> or if this should be handled inside the library and
>> integrateOneStep will be the only API one step function
>>
>
> my preference is to have only one API one step function

Ok, I guess the few if statments in the integrateOneStep will not be 
really a performance drawback.

Initially, I made the cvodeOneStep and simpleOneStep functions public 
(part of the API) to enable the most direct use of a specific solver for 
applications that know what type of model they have.

It would be easy but is not possible anymore with the

 	engine->processEvents

option, set within above discussed function, unless we add

cvodeOneStepWithoutEventProcessing
simpleOneStepWithoutEventProcessing

and eventually

idaOneStepWithoutEventProcessing

and others.

The integratorOneStep was thought to be a simple wrapper for applications 
that don't know there model types.

Rainer




>> -----Original Message-----
>> From: sbm...@li...
>> [mailto:sbm...@li...] On
>> Behalf Of Rainer Machne
>> Sent: 19 April 2006 14:56
>> To: SOSlib Development
>> Subject: [SOSlib-devel] simple event handling corrected[Scanned]
>>
>> Hi All
>>
>> Just wanted to let you know, that I have submitted a
>> (hopefully) corrected version of the simple event handling.
>>
>> TODOs found:
>>
>> * clean up the use of the SBML_ODESOLVER_API tag (part of C++
>> API todo)
>>
>> * decide wheter private functions should be declared at the
>> header of the c file
>>
>> * remove redundant function II_checkTrigger or alternatively
>> * provide this function as API -- maybe without the event execution ??
>>
>>
>> * decide on whether or not to have API functions for
>> solverOneStep (for each solver, no ODES, CVODES, IDA, etc.)
>> or if this should be handled inside the library and
>> integrateOneStep will be the only API one step function
>>
>> Rainer
>>
>>
>>
>>
>> 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 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
>>>>>
>>>>
>>>
>>
>>
>> -------------------------------------------------------
>> 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=lnk&kid=120709&bid=263057&
>> dat=121642
>> _______________________________________________
>> sbmlsolver-devel mailing list
>> sbm...@li...
>> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>>
>

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

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

Andrew

On Wed, 19 Apr 2006, Andrew Finney wrote:
>> Would people support a convention that we still declare such
>> private functions in the header of the c file, in which they are used?
>>
>
> Hmmm
>
> Do you mean the .h file or the top section of the .c file?

I meant the top section of the .c file.

>
> my preference is for
>
> a) no redundant prototypes (simple is best) i.e. only used where a
> forward declaration is needed

Personally, I like to have nice lists of all existing functions, i.e. 
header files (.h) plus declarations at the top section of .c files for 
static functions. It just makes it easier for me to recall the exact order 
of function calls, without parsing throught the source.

However, as it is not necessary for doxygen, we could remove all 
declarations of static functions in .c file, if people wish so.


> b) if they are necessary they go in the .c file as a first resort

I can't think of a case where this would be necessary, if the function is 
only used within this .c file.

Can't you always just write the function before it is used? Does this also 
work for recursive functions? Sorry for my illiteracy with such basic 
stuff :-)


> c) if they are required to be in a header but they are not part of the
> API
>    they should go in a header like:  intergatorInstance_internal.h
>   In the long term we ought to separate the API prototypes from the
>   internal prototypes in two separate sets of headers so that
> applications
>   can clearly see what is the API.

Agree.


> d) any other case is public!

I.e. either in ...internal.h or in API .h files, right?

> e) don't use SBML_ODESOLVER_API unless the function is strictly part
> of the API (I'm guilty too)

Agree.


>
>> 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.
>
> Can you explain this in detail please?
> What do you mean 'outside of a doxygen documentation block'?


A doxygen documentation block starts with

 	/*@{*/

and ends with

 	/*}@*/


However, I was wrong with the above statement.

If the function does NOT contain any

 	/** or /*!

comments, then it will NOT be part of the documentation.

Thus static and non API functions should ONLY use /* comments.

I just corrected the doxygen template c file at
http://www.tbi.univie.ac.at/~raim/odeSolver/data/doxygenComments.c

Rainer


>
>> -----Original Message-----
>> From: Rainer Machne [mailto:ra...@tb...]
>> Sent: 19 April 2006 14:48
>> To: Andrew Finney
>> Cc: SOSlib Development
>> Subject: RE: [SOSlib-devel] RE: comment on proposed exact
>> event implementation[Scanned]
>>
>> 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
>>>>>
>>>>
>>>
>>
>

RE: [SOSlib-devel] simple event handling corrected[Scanned]

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

Rainer

you wrote:

> * clean up the use of the SBML_ODESOLVER_API tag (part of C++=20
> API todo)

yes

>=20
> * decide wheter private functions should be declared at the=20
> header of the c file
>=20

see last email

> * remove redundant function II_checkTrigger or alternatively
> * provide this function as API -- maybe without the event execution ??
>=20
>=20

if it aint called get rid of it

> * decide on whether or not to have API functions for=20
> solverOneStep (for each solver, no ODES, CVODES, IDA, etc.)=20
> or if this should be handled inside the library and=20
> integrateOneStep will be the only API one step function
> =20

my preference is to have only one API one step function

yours Andrew

> -----Original Message-----
> From: sbm...@li...=20
> [mailto:sbm...@li...] On=20
> Behalf Of Rainer Machne
> Sent: 19 April 2006 14:56
> To: SOSlib Development
> Subject: [SOSlib-devel] simple event handling corrected[Scanned]
>=20
> Hi All
>=20
> Just wanted to let you know, that I have submitted a=20
> (hopefully) corrected version of the simple event handling.
>=20
> TODOs found:
>=20
> * clean up the use of the SBML_ODESOLVER_API tag (part of C++=20
> API todo)
>=20
> * decide wheter private functions should be declared at the=20
> header of the c file
>=20
> * remove redundant function II_checkTrigger or alternatively
> * provide this function as API -- maybe without the event execution ??
>=20
>=20
> * decide on whether or not to have API functions for=20
> solverOneStep (for each solver, no ODES, CVODES, IDA, etc.)=20
> or if this should be handled inside the library and=20
> integrateOneStep will be the only API one step function
>=20
> Rainer
>=20
>=20
>=20
>=20
> On Wed, 19 Apr 2006, Andrew Finney wrote:
>=20
> > Rainer
> >
> > IntegratorInstance_processEventsAndAssignments
> >
> > doesn't have a declaration: its not required as its not part of the=20
> > API the SBML_ODESOLVER_API qualification is redundant - I=20
> guess that=20
> > confused you That's my fault.  Remind me to update the dynalically=20
> > 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=20
> >> 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=20
> >> 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=20
> >> 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=20
> >> 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=20
> 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=20
> 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=20
> >>>> `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=20
> >>>> II_integrateOneStepWithoutEventProcessing. I guess you=20
> 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
> >> 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] =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 &&=20
> evaluateAST(trigger, data) )
> >>>>>>>>>>>     fired++; (leading to assignment execution in
> >> calling code)
> >>>>>>>>>>>     data->trigger[i] =3D 1;
> >>>>>>>>>>>   else
> >>>>>>>>>>>     data->trigger[i] =3D 0;
> >>>>>>>>>>
> >>>>>>>>>> means that event triggers are set to 0, whenever they
> >>>>>> have already
> >>>>>>>>>> been fired, even when the trigger is still true.
> >>>>>>>>>>
> >>>>>>>>>> That means that events are again executed in the time step=20
> >>>>>>>>>> afterwards, even if they have been true ever since
> >> their last
> >>>>>>>>>> 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=20
> as they are
> >>>>>>>>>> true, but
> >>>>>>>>>>>> their assignments are only evaluated when they
> >> were 0 before.
> >>>>>>>>>>>>
> >>>>>>>>>>>> This should do it, right?
> >>>>>>>>>>>>
> >>>>>>>>>>>> In the current version it is wrong:
> >>>>>>>>>>>>
> >>>>>>>>>>>> It's the line 636 in integratorInstance
> >>>>>>>>>>>>
> >>>>>>>>>>>>   if ( data->trigger[i] =3D=3D 0 &&
> >> evaluateAST(trigger, data) )
> >>>>>>>>>>>>     fired++; (leading to assignment execution in
> >>>> calling code)
> >>>>>>>>>>>>     data->trigger[i] =3D 1;
> >>>>>>>>>>>>   else
> >>>>>>>>>>>>     data->trigger[i] =3D 0;
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> I.e. it misses the evaluation for false=20
> 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=20
> 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=20
> an epsilon
> >>>>>>>>>> with root
> >>>>>>>>>>>>> finding switched off :-(
> >>>>>>>>>>>>> 	(the algorithm I posted didn't include=20
> 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=20
> 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=20
> 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
> >> 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=20
> 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=20
> further be
> >>>>>>>>>>>> subdivided:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> e.g.:
> >>>>>>>>>>>>>> trigger a < 10 || b > 20
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> can be handled as two separate triggers, while and
> >>>>>>>> exclusive OR
> >>>>>>>>>>>>>> needs combined handling again as outlined before:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> e.g.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> trigger: a < 10 && b > 20
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> becomes to root conditions in the function g:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> a - 10 =3D 0;
> >>>>>>>>>>>>>> b - 20 =3D 0;
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> * keep integrating if only  a or b is true
> >>>>>>>>>>>>>> * exact event happens when the second conditions also
> >>>>>>>>>> becomes true
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> This can become tricky. As far as I understood the root
> >>>>>>>>>> finder, it
> >>>>>>>>>>>>>> stops integrating at the time where it found the root.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Thus we might have to include a code
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> if ( triggerWasTrue )
> >>>>>>>>>>>>>>   rootFunction =3D 1.0;
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> to supress root finding for triggers that are
> >> already true.
> >>>>>>>>>>>>>> The same should probably be done for combined
> >>>>>>>> triggers, for the
> >>>>>>>>>>>>>> expression that becomes true first and needs=20
> 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
> >>>>>>>>>>>>>> =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
> >> 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
> >> expressions 10 - a
> >>>>>>>>>>>>>>>> =3D=3D 0 and b -
> >>>>>>>>>>>>>>>>>> 10 =3D=3D 0
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> when you find a root you re-evaluate the complete
> >>>>>>>>>>>>>> triggers to see
> >>>>>>>>>>>>>>>>>> what's really fired.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> or is there a better approach?
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Are there other forms of events, where this
> >> method can
> >>>>>>>>>>>>>>>> not be applied?
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Well there is equality e.g. x =3D=3D 40 I think
> >> that should
> >>>>>>>>>>>>>> work as x -
> >>>>>>>>>>>>>>>>>> 40 =3D=3D 0 Inequality is fine to you map x !=3D 40 =
to x
> >>>>>>>> - 40 =3D=3D 0
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> In both cases you need to revaluate the trigger
> >>>>>>>>>> expression but
> >>>>>>>>>>>>>>>>>> probably with an epsilon (especially=20
> 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=20
> evaluate the
> >>>>>>>>>> expression
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> leftChildofTrigger - rightChildOfTrigger
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> for which the root finder tries to find a=20
> 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=20
> 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=20
> drastically
> >>>>>>>>>>>>>>>> slowes down
> >>>>>>>>>>>>>>>>>>>> the integration speed especially if we
> >> have a lot of
> >>>>>>>>>>>> triggers!
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> the other problem which we did not touch=20
> 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=20
> 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=20
> 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=20
> 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=20
> >>> Apache Geronimo
> >>>
> >>=20
> http://sel.as-us.falkag.net/sel?cmd__________________________________
> >> _
> >>> ____________
> >>> sbmlsolver-devel mailing list
> >>> sbm...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
> >>>
> >>
> >
>=20
>=20
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web=20
> services, security?
> Get stuff done quickly with pre-integrated technology to make=20
> your job easier Download IBM WebSphere Application Server=20
> v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&
> dat=3D121642
> _______________________________________________
> sbmlsolver-devel mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>=20

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

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

Rainer

you wrote:

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

Hmmm

Do you mean the .h file or the top section of the .c file?

my preference is for

a) no redundant prototypes (simple is best) i.e. only used where a
forward declaration is needed
b) if they are necessary they go in the .c file as a first resort
c) if they are required to be in a header but they are not part of the
API
    they should go in a header like:  intergatorInstance_internal.h
   In the long term we ought to separate the API prototypes from the
   internal prototypes in two separate sets of headers so that
applications
   can clearly see what is the API.
d) any other case is public!

e) don't use SBML_ODESOLVER_API unless the function is strictly part
of the API (I'm guilty too)

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

Can you explain this in detail please?
What do you mean 'outside of a doxygen documentation block'?

yours Andrew

> -----Original Message-----
> From: Rainer Machne [mailto:ra...@tb...]=20
> Sent: 19 April 2006 14:48
> To: Andrew Finney
> Cc: SOSlib Development
> Subject: RE: [SOSlib-devel] RE: comment on proposed exact=20
> event implementation[Scanned]
>=20
> Andrew
>=20
> On Wed, 19 Apr 2006, Andrew Finney wrote:
>=20
> > Rainer
> >
> > IntegratorInstance_processEventsAndAssignments
> >
> > doesn't have a declaration: its not required as its not part of the=20
> > API the SBML_ODESOLVER_API qualification is redundant - I=20
> guess that=20
> > confused you
>=20
> Exactly, that was it. Sorry for the confusion.
>=20
> I understand, that it isn't required to declare such=20
> functions, if they are defined before the are used.
>=20
> Would people support a convention that we still declare such=20
> private functions in the header of the c file, in which they are used?
>=20
> This would also allow to put private functions all together=20
> outside of a doxygen documentation block. Otherwise the=20
> functions will be included in the documentation, or have each=20
> to be surrounded by end/start tags for documentation blocks.
>=20
> Rainer
>=20
>=20
> > That's my fault.  Remind me to update the dynalically=20
> compiled version=20
> > 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=20
> >> 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=20
> >> 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=20
> >> 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=20
> >> 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=20
> 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=20
> 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=20
> >>>> `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=20
> >>>> II_integrateOneStepWithoutEventProcessing. I guess you=20
> 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
> >> 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] =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 &&=20
> evaluateAST(trigger, data) )
> >>>>>>>>>>>     fired++; (leading to assignment execution in
> >> calling code)
> >>>>>>>>>>>     data->trigger[i] =3D 1;
> >>>>>>>>>>>   else
> >>>>>>>>>>>     data->trigger[i] =3D 0;
> >>>>>>>>>>
> >>>>>>>>>> means that event triggers are set to 0, whenever they
> >>>>>> have already
> >>>>>>>>>> been fired, even when the trigger is still true.
> >>>>>>>>>>
> >>>>>>>>>> That means that events are again executed in the time step=20
> >>>>>>>>>> afterwards, even if they have been true ever since
> >> their last
> >>>>>>>>>> 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=20
> as they are
> >>>>>>>>>> true, but
> >>>>>>>>>>>> their assignments are only evaluated when they
> >> were 0 before.
> >>>>>>>>>>>>
> >>>>>>>>>>>> This should do it, right?
> >>>>>>>>>>>>
> >>>>>>>>>>>> In the current version it is wrong:
> >>>>>>>>>>>>
> >>>>>>>>>>>> It's the line 636 in integratorInstance
> >>>>>>>>>>>>
> >>>>>>>>>>>>   if ( data->trigger[i] =3D=3D 0 &&
> >> evaluateAST(trigger, data) )
> >>>>>>>>>>>>     fired++; (leading to assignment execution in
> >>>> calling code)
> >>>>>>>>>>>>     data->trigger[i] =3D 1;
> >>>>>>>>>>>>   else
> >>>>>>>>>>>>     data->trigger[i] =3D 0;
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> I.e. it misses the evaluation for false=20
> 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=20
> 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=20
> an epsilon
> >>>>>>>>>> with root
> >>>>>>>>>>>>> finding switched off :-(
> >>>>>>>>>>>>> 	(the algorithm I posted didn't include=20
> 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=20
> 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=20
> 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
> >> 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=20
> 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=20
> further be
> >>>>>>>>>>>> subdivided:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> e.g.:
> >>>>>>>>>>>>>> trigger a < 10 || b > 20
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> can be handled as two separate triggers, while and
> >>>>>>>> exclusive OR
> >>>>>>>>>>>>>> needs combined handling again as outlined before:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> e.g.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> trigger: a < 10 && b > 20
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> becomes to root conditions in the function g:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> a - 10 =3D 0;
> >>>>>>>>>>>>>> b - 20 =3D 0;
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> * keep integrating if only  a or b is true
> >>>>>>>>>>>>>> * exact event happens when the second conditions also
> >>>>>>>>>> becomes true
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> This can become tricky. As far as I understood the root
> >>>>>>>>>> finder, it
> >>>>>>>>>>>>>> stops integrating at the time where it found the root.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Thus we might have to include a code
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> if ( triggerWasTrue )
> >>>>>>>>>>>>>>   rootFunction =3D 1.0;
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> to supress root finding for triggers that are
> >> already true.
> >>>>>>>>>>>>>> The same should probably be done for combined
> >>>>>>>> triggers, for the
> >>>>>>>>>>>>>> expression that becomes true first and needs=20
> 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
> >>>>>>>>>>>>>> =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
> >> 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
> >> expressions 10 - a
> >>>>>>>>>>>>>>>> =3D=3D 0 and b -
> >>>>>>>>>>>>>>>>>> 10 =3D=3D 0
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> when you find a root you re-evaluate the complete
> >>>>>>>>>>>>>> triggers to see
> >>>>>>>>>>>>>>>>>> what's really fired.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> or is there a better approach?
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Are there other forms of events, where this
> >> method can
> >>>>>>>>>>>>>>>> not be applied?
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Well there is equality e.g. x =3D=3D 40 I think
> >> that should
> >>>>>>>>>>>>>> work as x -
> >>>>>>>>>>>>>>>>>> 40 =3D=3D 0 Inequality is fine to you map x !=3D 40 =
to x
> >>>>>>>> - 40 =3D=3D 0
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> In both cases you need to revaluate the trigger
> >>>>>>>>>> expression but
> >>>>>>>>>>>>>>>>>> probably with an epsilon (especially=20
> 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=20
> evaluate the
> >>>>>>>>>> expression
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> leftChildofTrigger - rightChildOfTrigger
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> for which the root finder tries to find a=20
> 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=20
> 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=20
> drastically
> >>>>>>>>>>>>>>>> slowes down
> >>>>>>>>>>>>>>>>>>>> the integration speed especially if we
> >> have a lot of
> >>>>>>>>>>>> triggers!
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> the other problem which we did not touch=20
> 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=20
> 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=20
> 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=20
> 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=20
> >>> Apache Geronimo
> >>>
> >>=20
> http://sel.as-us.falkag.net/sel?cmd__________________________________
> >> _
> >>> ____________
> >>> sbmlsolver-devel mailing list
> >>> sbm...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
> >>>
> >>
> >
>=20

[SOSlib-devel] simple event handling corrected

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

Hi All

Just wanted to let you know, that I have submitted a (hopefully) corrected 
version of the simple event handling.

TODOs found:

* clean up the use of the SBML_ODESOLVER_API tag (part of C++ API todo)

* decide wheter private functions should be declared at the header of the 
c file

* remove redundant function II_checkTrigger
or alternatively
* provide this function as API -- maybe without the event execution ??


* decide on whether or not to have API functions for solverOneStep (for 
each solver, no ODES, CVODES, IDA, etc.) or if this should be handled 
inside the library and integrateOneStep will be the only API one step 
function

Rainer




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
> 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
>>>
>>
>

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
>>>
>>
>

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

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

Andrew, Xtof,


Sorry for the confusion. I have a declaration for

> > > II_integrateOneStepWithoutEventProcessing.

but I was actually searching for the declaration of

SBML_ODESOLVER_API int IntegratorInstance_processEventsAndAssignments(integratorInstance_t 
*engine)

Rainer





On Wed, 19 Apr 2006, Christoph Flamm wrote:

> 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
>
>

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

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

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

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

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

Ok, I'll delete my file and try update again.

At the lib/sbml lists people already reported several problems with CVS. 
It's also strange that the online CVS is some much behind for this file, 
while having newer versions of other files.

Rainer


On Wed, 19 Apr 2006, Christoph Flamm wrote:

> 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
>
>

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

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

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
>

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

[Christoph F. <xt...@tb...>]

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