Talk:Event handling
Please add new comments below with a ==heading== and signed beneath using ~~~~. If responding to an earlier comment, prefix your comments with ":" so that they are indented, and sign as before.
REINIT and PRE
One basic implementation of boundary events would be to allow a REINIT statement in addition to the USE statement to exist inside WHEN..CASE. REINIT statments would be associated with a particular CASE, and whenever a CASE change occurred, it would trigger an ICP to be created and solved.
PRE could then be added to the language. PRE inside a 'normal' relation would trigger an error. PRE inside a REINIT statement would result in a callback to the solver, which would have to keep a copy of variable values before the current boundary.
REINIT x TO -0.9*pre(x);
This statement would set the new value of 'x' and perhaps remove 'x' from the initial value problem. The derivative of x would still need to be solved for, using the dynamic equations in the problem.
Jpye 10:55, 11 February 2012 (EST)
Initial condition problems
The major issues we have with event handling currently are
- defining 'edge' events as opposed to 'region conditions'
- flexibly declaring initial condition problems (ICPs)
Our current WHEN syntax defines region conditions pretty well. This means that a boundary is defined, and if the solver crosses that boundary, we have to change our equations, reinitialise the DAE system and then continue.
For 'edge' events, we don't necessarily want to change the equations in our system, we just want to be able to be able to reassign values to certain variables, such that instead of the default state-variable continuity being applied, we can create step changes and other effects.
We are currently missing in ASCEND the idea of ICPs in general, which is a precursor to the above. In DAEs, we have <math>n</math> state variables (variables plus derivatives) plus <math>m</math> algebraic equations. Normal integration time-stepping requires <math<n+m</math> equations. ICP solution requires <math>2n+m</math> equations, because we need to solve the initial derivatives as well as the state variables, plus all the algebraics.
In IDA, the ICP is currently solved by assuming the state variables are fixed, and using the DAE equations to solve the derivatives plus the algebraic variables.
More generally, we should be able to set ICPs both for the truly initial conditions, as well as for each time boundaries are crossed. We could use a SWITCH statement inside a METHOD to turn on and off equations in this cases as a first hack. This would require lots of inactive equations to be declared in the model, and in a method initcond we could prepare the initial condition problem, and in a method continue we could restore the DAE problem. Somewhere inside IDA, then, we would detect a boundary and RUN initcond, then run QRSlv, then run continue, the proceed with the integration.
The better solution would allow sometime like the CONDITIONAL statement, as a way to declare ICP equations. That section would in general need to allow conditional syntax such as supported by CMSlv.