Event handling

This article is about planned development or proposed functionality. Comments welcome.

Please add discussion/feedback on the 'discussion' page, restrict this page to description of the problem or a proposed solution/implementation.

To successfully implement integration of conditional models is quickly becomes apparent that simple boundary detection is only a small part of the whole problem. In general, we need to allow for 'events' to occur when a boundary is encountered, for variables to be re-set using abitrary equations and/or expressions, and potentially for difficult initial condition problems to be solved before integration (DAE/ODE) simulation can proceed.

Use cases

Some use cases that we would like to be able to support. These are all continuous-time simulations. We're not looking at adding pure discrete-event simulation at this stage.

• a bouncing ball that *instantly* reverses its velocity (or v(+) = -v(-) * 0.9, perhaps) when hitting the ground. Note that Leon's approach uses a springy floor, instead of the instant velocity reversal approach. Sometimes we don't want to have to add this extra physics to our simulation.
• thermostat controller: a house has thermal losses, but a heat is attached. Heater turns on when temperature below 18 °C, and turns off when temperature rises above 20 °C. Plot the room temperature as a function of time.
• solar house: in extension to above, add solar energy gain to the thermostat model. on some days, less heating input will be required.
• a tank becoming full and starting to overflow
• a flow rate controller that increments flow in fixed steps when certain thresholds are passed.
• a vessel with an inlet in the side, and an outlet protruding into the pipe from above; if the level is above the outlet, liquid comes out; if the level is below, gas (or nothing) comes out. 'sliding mode' is when a system like this gets stuck on the boundary or oscilates rapidly across it. how do we deal with that? User:Kannan is our expert on this kind of system.
• annual performance of a solar power plant, including rules like "wait half and hour after sunrise before starting the turbine" and "when storage is full, start dumping heat", using external weather data and demand data to drive the control-system part of the simulation.
• reporting of model 'state' (boolean variables) alongside real variable outputs.

Implementation issues

ASCEND currently supports WHEN and CONDITIONAL statements, allowing for models with boundaries and boundary switching behaviour of a specific limited type. ASCEND lacks support for the following:

• 'boundary equations', eg "when temperature = 20 °C, increase flowrate by 1 L/s", or "Vdot(+) = Vdot(-) + 1 {L/s}".
• 'events': things that are executed exactly once, when first arriving at or on a boundary.
• initial condition problems: there is no control over the equations used to reinitialise after a boundary. We just the the IDACalcIC built-in method.
• convenient derivative syntax, eg "der(x) = -x".
• any means to convey boolean states back from an external relation, meaning that it is difficult to trigger events based on the state of external code.

Instead, ASCEND allows only equations to be turned off and turned as the solver moves across the boundary. There is no way to trigger and special behaviour or action at the boundary. This means that currently, we can not implement a 'true' bouncing ball model, nor a thermostat model.

Modelica implementation

The Modelica language has some solutions in their syntax documentation to these problems that are worth consideration:

• when-equations are executed at a boundary
  • when-equation are not free-form equations, they are only allowed to be x = expr assignment statements
  • when..elsewhen allows queuing/prioritisation of event handlers (queued cases are only allowed when the variables (x) being assigned match in all the nested when-equations
• initial equations are used to provide a initial condition problem to the solver (but we need to clarify if that only happens at the start of simulation, or at every boundary)
• pre(x) inside a when-clause returns the value of a simulation variable before the current boundary.
• reinit(x, expr) re-initialises a variable to a new value upon crossing a boundary
  • using reinit forces Modelica to check that the variable 'x' is a state variable in the DAE simulation.
  • reinit has the effect of setting variable 'x' to be unknown, and adding a new equation 'x = expr'.
  • a standard when-equation has the effect of simply adding a new ewquation 'x = expr', but not setting 'x' as unknown.
• various sub-expressions trigger boundaries to be 'emitted' from a relation, and added the the solver's boundary list.
• noevent(...) allows suppression of triggered boundaries
• smooth(...) forces the solver to treat expressions as continuously differentiable. we assume this is related to boundary suppression.

gPROMS solution

The thesis by Paul Barton also has a solution for this problem.

Other implementations?

Some other possible implementations/solutions worth researching:

• MOSILAB webpage and paper.
• A list of discrete event simulation software

Proposed solution

We don't know how we'll do it. Please give your thoughts on the discussion page.

A decent explanation of the full design space is in Fishwick

References

There are further references in integration of conditional models