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

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

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

Rainer

strange

I have the declaration at=20
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...]=20
> Sent: 19 April 2006 12:42
> To: Andrew Finney
> Cc: SOSlib Development
> Subject: RE: comment on proposed exact event implementation[Scanned]
>=20
> Andrew
>=20
> I have correct the simple event detection, so that it doesn't=20
> set trigger flags to 0, if the trigger is actually still fired.
>=20
> Some questions regarding the new code:
>=20
> Now that enginge->processEvents is set either to 1 or to 0 in=20
> II_integrateOneStep and II_integrateOneStepWithoutEventProcessing,
> respectively, the functions
>=20
> II_simpleOneStep and II_cvodeOneStep
>=20
> shouldn't be public anymore.
>=20
> Before this new switch, they were public, so that=20
> applications which knew what type of solver is required=20
> (currently ODEs or no ODEs, but eventually also DAEs or even=20
> stochastic solvers) can use these `solver'OneStep functions directly.
>=20
> Should we remove these functions from the API or should we=20
> keep the possibility to use different solvers directly?
>=20
> In the second case we need to move the engine->processEvents=20
> setting to some other place!
>=20
> Also I didn't find a function declaration for=20
> II_integrateOneStepWithoutEventProcessing. I guess you wanted=20
> this function to be public, or did you just use it for testing?
>=20
>=20
> Rainer
>=20
>=20
>=20
>=20
> On Wed, 19 Apr 2006, Andrew Finney wrote:
>=20
> > 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=20
> implementation[Scanned]
> >>
> >> Andrew
> >>
> >>> I'm more worried about the performance hit of 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 - as outlined=20
> >> two emails below - and submit it, or do you think it would=20
> slow down=20
> >> 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=20
> evaluating the not=20
> >>>>> 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=20
> evaluations=20
> >>>> 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=20
> >>>>>> afterwards, even if they have been true ever since 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=20
> evaluated before=20
> >>>>>> 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=20
> time 0. So=20
> >>>>>>>> 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.=20
> They stay 1=20
> >>>>>>>> (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=20
> 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=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.
> >>>>>>>>>
> >>>>>>>>> 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=20
> >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 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 [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=20
> to evaluate
> >>>>>>>>>>>> letfChild -
> >>>>>>>>>>>>> rightChild works in general to find the exact=20
> 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=20
> 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=20
> 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 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 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.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
>=20

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

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

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

[SOSlib-devel] Re: ... + testing strategy

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

Andrew

Sorry, for the late response to this one:

On Tue, 11 Apr 2006, Andrew Finney wrote:
> Rainer and Christoph
>
> Did you manage to talk to Ben B about testing frameworks for C code at 
the Hackathon?

No.

> If not should I compose an email?

Yes, that would be great!

Rainer

Re: [SOSlib-devel] Re: Parameter Scan functions in SOSlib

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

Hi Eryk,

> Yes, parameter scans are important and must be supported by Soslib at this
> stage.

As Akira already explained, we decided this at the hackathon 2005, and 
one main reason was that SOSlib wasn't a library back then, and it wasn't 
and still isn't simple to create bindings.

Also, at that time, the interfaces to the integrator itself were not as 
fine-grained and an external application couldn't do the scan as 
efficiently as an internal SOSlib function.

One important point of our current todo list is `C++ bindings' or actually 
C++ versions of all trivial structures, like cvodeResults, SBMLResults, 
and cvodeSettings and get/set methods. This will make it much easier to 
generate bindings via SWIG.

The SBML/Model_odeSolverBatch functions were supposed to be the most 
high-level interface to SOSlib. With the new interface and with bindings 
these functions might not be required anymore in SOSlib.

In the meantime, we should maybe repair the existing Batch functions in 
the way you originally suggested them. See below.

> A sufficient support for parameter scans would be if there are functions
> which enable to change a value of one or more variables and afterwards to
> evaluate (integrate) the model. I understand this can be accomplished by one
> or several calls to "IntegratorInstance_setVariableValue"?

Yes, this function is thought for such purposes. It works on the level of 
the integratorInstance, and thus you don't need to parse the SBML again, 
reconstruct the ODE model or allocate the integrator.

It can even safely set all values of a model DURING integration steps. If 
you change an ODE variable during the integration, then the integrator 
must be reinitialized.
This latter usage actually allows to have external events. 
It is useful for e.g. multi-scale models, but i could also imagine some 
sort of use in parameter testing routines ... Can anyone think of such 
applications?


> I have suggested a few months ago and submitted code which takes new values
> for one or more variables ( a so called design point), sets them and returns
> a SBMLResult.

> Furthermore I suggested to include and submitted code for a function which
> given a set of design points returns an array of SBMLResults. Given this
> function it is trivial to generate a 2D Cartesian design requested by
> Norhiko.
>
> However I can not find this functions which would enable me to interface
> easily with soslib.
>
> Instead, I find a lot of very specialized function which generate a concrete
> experimental design. In my opinion such functions  should not be included
> into soslib at least at this stage for the following reasons:
>
> First, given the functions suggested above it would be easily possible for a
> library user, the application developer, to implement any concrete design he
> needs. Norihiro, why do you think that the parameter scan should be
> implemented in Soslib and not in CellDesigner?

...
> Lets take a look at Model_odeSolverBatch.
> Rainer, what kind of design this function generates? I don't understand. What
> are the references? Why a 2D matrix representation of the results is
> generated? The same questions I have to ask regarding your question 1 and 2
> below.

... and in a later email:

> I do mind a bit, if generic functions, already written and submitted to
> soslib, which would enable to interface between existing libraries and
> soslib, are not supported.


The initial purpose of the current SBML/Model_odeSolverBatch functions was 
actually to realize your (Eryk's) ideas within SOSlib, and as a general
version of the old parameter scan interface function for CellDesigner!!

I didn't take your code directly, because it just called Model_odeSolver 
for each parameter value. This includes new construction of the ODE system 
and new allocation of the integrator. So the idea was to embed it in 
SOSlib in the most efficient way and with our internal error handling.

But I just messed up! As already stated in my first email. They really 
don't do what they are supposed to.

The problem was, that I merged your design function with the Batch 
function without using my brain. They actually do something different. So 
I ended up with functions that don't do either thing correctly. Shame on 
me.

And I strongly apologize, for not acknoweldging your contribution in the 
file headers, but with the last facts told, this was better anyways :-)
It all happened within a large-scale and high-speed programming session 
generating a large set of new API functions last autumn.

To make a new corrected version of all this I started this discussion.

So as a conclusion, I will take a look again at your functions, Eryk, and 
try to optimize them for SOSlib.

Alternatively, I could leave my hands off it and you can redo them, using 
our error handling and the finegrained interface to the integrator.

Rainer











On Thu, 13 Apr 2006, Witold Eryk Wolski wrote:

> Hi Rainer and all,
>
>
> Yes, parameter scans are important and must be supported by Soslib at this 
> stage. However, there are so many strategies to construct designs (parameter 
> scans) that I am not sure if they should be part of soslib at any stage.
>
> A sufficient support for parameter scans would be if there are functions 
> which enable to change a value of one or more variables and afterwards to 
> evaluate (integrate) the model. I understand this can be accomplished by one 
> or several calls to "IntegratorInstance_setVariableValue"?
>
> I have suggested a few months ago and submitted code which takes new values 
> for one or more variables ( a so called design point), sets them and returns 
> a SBMLResult.
>
> Furthermore I suggested to include and submitted code for a function which 
> given a set of design points returns an array of SBMLResults. Given this 
> function it is trivial to generate a 2D Cartesian design requested by 
> Norhiko.
>
> However I can not find this functions which would enable me to interface 
> easily with soslib.
>
> Instead, I find a lot of very specialized function which generate a concrete 
> experimental design. In my opinion such functions  should not be included 
> into soslib at least at this stage for the following reasons:
>
> First, given the functions suggested above it would be easily possible for a 
> library user, the application developer, to implement any concrete design he 
> needs. Norihiro, why do you think that the parameter scan should be 
> implemented in Soslib and not in CellDesigner?
>
> Secondly, adding functions to generate a concrete designs to soslib makes the 
> library unecessarily more complex. Lets take a look at Model_odeSolverBatch. 
> Rainer, what kind of design this function generates? I don't understand. What 
> are the references? Why a 2D matrix representation of the results is 
> generated? The same questions I have to ask regarding your question 1 and 2 
> below.
>
>
> Frohe Ostern
>
> Happy Eastern.
>
>
>
> Rainer Machne wrote:
>> Hi Akira, Eryk and Norihiro,
>> 
>> (CCed also to the SOSlib development list)
>> 
>> you are all using/interested in the high-level SOSlib interface 
>> SBML_odeSolverBatch for efficient parameter/initial condition scans.
>> 
>> Currently, it is implemented with a serious and stupid malfunction - i.e. n 
>> parameters can be varied over m arbitrary points (design points), but there 
>> are no combinations of parameter values.
>> 
>> CellDesigner needs results for each combination of parameter values, and 
>> this is the general requirement for such a batch function.
>> I want to correct this now.
>> 
>> There are two questions:
>> 
>> 1) Do you see a need for n parameters to be varied, and to get a result 
>> structures for each combination? This would result in a n*n*m*m matrix of 
>> SBMLResults. Or is it generally sufficient to provide this scan only for 2 
>> parameters?
>> 
>> 2) As we now want to vary over m arbitrary design points, m (the number of 
>> parameter values to be scanned for one parameter) could be different for 
>> each parameter. I.e. one parameter might be varied over 3 values, while the 
>> other parameter might be varied over 16 values.
>> 
>> Implementing 2, i.e. a different m for each parameter would be much easier 
>> if we restrict the batch function to 2 parameters!
>> 
>> What do you think? Or better asked: what are your requirements?
>> 
>> If you want you can add things to the respective section at
>> http://www.tbi.univie.ac.at/wiki/index.php/SOSlibDevel#Batch_Mode_for_Parameter_Scan 
>> (email ha...@tb... to get an account, mention that you want to 
>> contribute to SOSlibDevel Wiki).
>> 
>> Rainer
>> 
>> 
>
>

Re: [SOSlib-devel] Re: Parameter Scan functions in SOSlib

[Witold E. W. <W.E...@nc...>]

Hi Akira,

In case of the Cartesian design it is trivial and computationally cheap 
to generate it. I assume that java  1.5 has a "for" loop statement? I 
remember Java 1.3 had one. I also think to remember that the jit 
compiler was good in optimising this kind of statements. So it should be 
easily possible to generate a cartesian design in java, pass it to 
soslib, evaluate the model at the points  and obtain the results, using 
the functions I have submitted.

There are many possible experimental designs and there are libraries 
dedicated to generate them. For example GSL has functions to generate 
the Sobol Sequence or the Niederreiter Sequences. Including such 
functionality into soslib is reinventing the weel and not as I have 
sugested leaving it out.

I do mind a bit, if generic functions, already written and submitted to 
soslib, which would enable to interface between existing libraries and 
soslib, are not supported.

cheers




Eryk
Akira Funahashi wrote:
> Hi,
> 
> At Thu, 13 Apr 2006 18:44:55 +0200,
> Witold Eryk Wolski <W.E...@nc...> wrote:
> 
>>First, given the functions suggested above it would be easily
>>possible for a library user, the application developer, to implement
>>any concrete design he needs. Norihiro, why do you think that the
>>parameter scan should be implemented in Soslib and not in
>>CellDesigner?
> 
> 
> This is what we (Rainer, Christoph, Norihiro and me) have discussed at
> the previous SBML Hackathon which was held in Japan. At that time,
> SOSlib was just started for its development (there already had an
> implementation of SBML ODE Solver itself, but not a library), and
> we've talked about which (SOSlib or CellDesigner) should implement
> parameter scan function.
> 
> The conclusion at that time was to implement it in SOSlib, because we
> thought supporting parameter scan in SOSlib will decrease the
> development cost for each programmer who will use SOSlib. Usually,
> libraries are developed to avoid reinvesting a wheel by other
> developers, and we thought that parameter scan will be in this topic.
> 
> Also, CellDesigner is implemented in Java, so it would be nice to
> reduce the overhead by the programming language. Usually C is faster
> than Java, so that we though it would benefit us to just wrap the
> C function from Java.
> 
> # OK, I know that current JIT technology really rocks, so under some
> # circumstance (variable type, data cache size, instruction cache
> # size, etc.) Java can beat C++, but it's not a usual thing...
> 
> Thanks,

-- 
Witold Eryk Wolski
__("<  School of Mathematics and Statistics     _
\__/   University of Newcastle                 'v'
  ||    Newcastle upon Tyne, NE1 7RU, ENGLAND  /   \
  ^^    mail: wi...@us...     m m
        http://www.mas.ncl.ac.uk/~nwew
        http://www.newcastletango.org.uk

Re: [SOSlib-devel] Re: Parameter Scan functions in SOSlib

[Akira F. <fu...@sy...>]

Hi,

At Thu, 13 Apr 2006 18:44:55 +0200,
Witold Eryk Wolski <W.E...@nc...> wrote:
> First, given the functions suggested above it would be easily
> possible for a library user, the application developer, to implement
> any concrete design he needs. Norihiro, why do you think that the
> parameter scan should be implemented in Soslib and not in
> CellDesigner?

This is what we (Rainer, Christoph, Norihiro and me) have discussed at
the previous SBML Hackathon which was held in Japan. At that time,
SOSlib was just started for its development (there already had an
implementation of SBML ODE Solver itself, but not a library), and
we've talked about which (SOSlib or CellDesigner) should implement
parameter scan function.

The conclusion at that time was to implement it in SOSlib, because we
thought supporting parameter scan in SOSlib will decrease the
development cost for each programmer who will use SOSlib. Usually,
libraries are developed to avoid reinvesting a wheel by other
developers, and we thought that parameter scan will be in this topic.

Also, CellDesigner is implemented in Java, so it would be nice to
reduce the overhead by the programming language. Usually C is faster
than Java, so that we though it would benefit us to just wrap the
C function from Java.

# OK, I know that current JIT technology really rocks, so under some
# circumstance (variable type, data cache size, instruction cache
# size, etc.) Java can beat C++, but it's not a usual thing...

Thanks,
-- 
Akira Funahashi, Ph.D. | Kitano Symbiotic Systems Project,
[fu...@sy...]| ERATO-SORST, JST

[SOSlib-devel] Re: Parameter Scan functions in SOSlib

[Witold E. W. <W.E...@nc...>]

Hi Rainer and all,


Yes, parameter scans are important and must be supported by Soslib at 
this stage. However, there are so many strategies to construct designs 
(parameter scans) that I am not sure if they should be part of soslib at 
any stage.

A sufficient support for parameter scans would be if there are functions 
which enable to change a value of one or more variables and afterwards 
to evaluate (integrate) the model. I understand this can be accomplished 
by one or several calls to "IntegratorInstance_setVariableValue"?

I have suggested a few months ago and submitted code which takes new 
values for one or more variables ( a so called design point), sets them 
and returns a SBMLResult.

Furthermore I suggested to include and submitted code for a function 
which given a set of design points returns an array of SBMLResults. 
Given this function it is trivial to generate a 2D Cartesian design 
requested by Norhiko.

However I can not find this functions which would enable me to interface 
easily with soslib.

Instead, I find a lot of very specialized function which generate a 
concrete experimental design. In my opinion such functions  should not 
be included into soslib at least at this stage for the following reasons:

First, given the functions suggested above it would be easily possible 
for a library user, the application developer, to implement any concrete 
design he needs. Norihiro, why do you think that the parameter scan 
should be implemented in Soslib and not in CellDesigner?

Secondly, adding functions to generate a concrete designs to soslib 
makes the library unecessarily more complex. Lets take a look at 
Model_odeSolverBatch. Rainer, what kind of design this function 
generates? I don't understand. What are the references? Why a 2D matrix 
representation of the results is generated? The same questions I have to 
ask regarding your question 1 and 2 below.


Frohe Ostern

Happy Eastern.



Rainer Machne wrote:
> Hi Akira, Eryk and Norihiro,
> 
> (CCed also to the SOSlib development list)
> 
> you are all using/interested in the high-level SOSlib interface 
> SBML_odeSolverBatch for efficient parameter/initial condition scans.
> 
> Currently, it is implemented with a serious and stupid malfunction - 
> i.e. n parameters can be varied over m arbitrary points (design points), 
> but there are no combinations of parameter values.
> 
> CellDesigner needs results for each combination of parameter values, and 
> this is the general requirement for such a batch function.
> I want to correct this now.
> 
> There are two questions:
> 
> 1) Do you see a need for n parameters to be varied, and to get a result 
> structures for each combination? This would result in a n*n*m*m matrix 
> of SBMLResults. Or is it generally sufficient to provide this scan only 
> for 2 parameters?
> 
> 2) As we now want to vary over m arbitrary design points, m (the number 
> of parameter values to be scanned for one parameter) could be different 
> for each parameter. I.e. one parameter might be varied over 3 values, 
> while the other parameter might be varied over 16 values.
> 
> Implementing 2, i.e. a different m for each parameter would be much 
> easier if we restrict the batch function to 2 parameters!
> 
> What do you think? Or better asked: what are your requirements?
> 
> If you want you can add things to the respective section at
> http://www.tbi.univie.ac.at/wiki/index.php/SOSlibDevel#Batch_Mode_for_Parameter_Scan 
> 
> (email ha...@tb... to get an account, mention that you want to 
> contribute to SOSlibDevel Wiki).
> 
> Rainer
> 
> 

-- 
Witold Eryk Wolski
__("<  School of Mathematics and Statistics     _
\__/   University of Newcastle                 'v'
  ||    Newcastle upon Tyne, NE1 7RU, ENGLAND  /   \
  ^^    mail: wi...@us...     m m
        http://www.mas.ncl.ac.uk/~nwew
        http://www.newcastletango.org.uk

[SOSlib-devel] Parameter Scan functions in SOSlib

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

Hi Akira, Eryk and Norihiro,

(CCed also to the SOSlib development list)

you are all using/interested in the high-level SOSlib 
interface SBML_odeSolverBatch for efficient parameter/initial condition 
scans.

Currently, it is implemented with a serious and stupid malfunction - 
i.e. n parameters can be varied over m arbitrary points (design points), 
but there are no combinations of parameter values.

CellDesigner needs results for each combination of parameter values, and 
this is the general requirement for such a batch function.
I want to correct this now.

There are two questions:

1) Do you see a need for n parameters to be varied, and to get a result 
structures for each combination? This would result in a n*n*m*m matrix of 
SBMLResults. Or is it generally sufficient to provide this scan only for 2 
parameters?

2) As we now want to vary over m arbitrary design points, m (the number of 
parameter values to be scanned for one parameter) could be different for 
each parameter. I.e. one parameter might be varied over 3 values, while 
the other parameter might be varied over 16 values.

Implementing 2, i.e. a different m for each parameter would be much easier 
if we restrict the batch function to 2 parameters!

What do you think? Or better asked: what are your requirements?

If you want you can add things to the respective section at
http://www.tbi.univie.ac.at/wiki/index.php/SOSlibDevel#Batch_Mode_for_Parameter_Scan
(email ha...@tb... to get an account, mention that you 
want to contribute to SOSlibDevel Wiki).

Rainer

[SOSlib-devel] formatting and documentation convention

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

Hi All,

please note that we now have conventions both for code formatting and for 
doxygen compatible documentation!

Our new Wiki page for development (email me, if you want an account to 
contribute) at
http://www.tbi.univie.ac.at/wiki/index.php/SOSlibDevel

provides two template files at
http://www.tbi.univie.ac.at/wiki/index.php/SOSlibDevel#Code_Style_and_Doxygen_Doc_Conventions

Please take a look and try to set your editors for the correct C 
formatting.

If you use emacs, you e.g. can add to your .emacs file

;; custom C modes
(require 'cc-mode)
;; formatting preferences
(c-set-offset 'substatement-open 0)

to overrule the (at least my) default settings - 2 spaces offset for the 
opening of a substatement - to 0 spaces.

http://www.bloomington.in.us/~brutt/emacs-c-dev.html gives other nice 
tricks for C programming in emacs, e.g. how to compile and debug within 
emacs.

Rainer

Re: [SOSlib-devel] switching to sbml-devel for development discussion + testing strategy

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

If you want, you could also take use of our local wiki.
At http://www.tbi.univie.ac.at/wiki/index.php/SOSlibDevel
I have collected the current plans for further development.

You need to create an account to contribute to this page and this has to 
be personally approved. So please let me know, if you want to contribute 
to this wiki page.

Rainer



On Tue, 11 Apr 2006, Andrew Finney wrote:

> Folks
>
> Please use this mailing list (sbm...@li...) for communicating development issues with SOSlib from now on.
>
> Its archived here:
> http://sourceforge.net/mailarchive/forum.php?forum_id=47160
>
> some of you would have got 2 copies of this message others at least one from SF.net  let me know if you didn't.
>
> [Stefanie - you will only get one!  do you want to be on this list (and thus an official developer of SOSlib)?]
>
> If other people should developers please get them to join source forge
> and then let me know their source forge user name and I'll make them
> developers of SOSlib.
>
> Let me know if you don't want to be a SOSlib developer
>
> First message:
>
> Rainer and Christoph
>
> Did you manage to talk to Ben B about testing frameworks for C code at the Hackathon?
> If not should I compose an email?
>
> yours Andrew
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd_______________________________________________
> sbmlsolver-devel mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbmlsolver-devel
>

[SOSlib-devel] check in

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

Folks

I have just checked in some code

this allows

- API access to the value array

- API facility to integrate one step without evaluating events

- adding new DLL exposed functions to CVODE

- adding CVODE to CompleteSOS lib .sln file for windows

Unfortunately I forgot to run dos2unix on the source files.
It is possible you'll run into compile bugs.

yours Andrew

[SOSlib-devel] switching to sbml-devel for development discussion + testing strategy

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

Folks

Please use this mailing list (sbm...@li...) =
for communicating development issues with SOSlib from now on.

Its archived here:=20
http://sourceforge.net/mailarchive/forum.php?forum_id=3D47160

some of you would have got 2 copies of this message others at least one =
from SF.net  let me know if you didn't.

[Stefanie - you will only get one!  do you want to be on this list (and =
thus an official developer of SOSlib)?]

If other people should developers please get them to join source forge
and then let me know their source forge user name and I'll make them
developers of SOSlib.

Let me know if you don't want to be a SOSlib developer

First message:

Rainer and Christoph

Did you manage to talk to Ben B about testing frameworks for C code at =
the Hackathon?
If not should I compose an email?

yours Andrew

[SOSlib-devel] test

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

hi andrew

this is a test. you're the only subscriber yet. i am just testing, if i 
get this email normally, or if i shoudl subscribe myself.

rainer