EVENT - Revision history

Jpye at 08:55, 24 March 2015

2015-03-24T08:55:51Z

← Older revision		Revision as of 08:55, 24 March 2015
Line 1:		Line 1:
	{{experimental}}		{{experimental}}
	The '''EVENT''' statement in ASCEND is used to declare named events in a [[dynamic modelling\|dynamic system model]]. The event is triggered by an inequality going from being false to being true. This is part of our work to support [[integration of conditional models]]. The syntax is		The '''EVENT''' statement in ASCEND is used to declare named events in a [[dynamic modelling\|dynamic system model]]. The event is triggered by an inequality going from being false to being true. This is part of our work to support [[integration of conditional models]], and was implemented in ASCEND by [[User:Ksenija\|Ksenija]]. The syntax is

	<source lang=a4c>		<source lang=a4c>

Jpye at 08:54, 24 March 2015

2015-03-24T08:54:47Z

← Older revision		Revision as of 08:54, 24 March 2015
Line 46:		Line 46:

	Note that currently the required solver code to run these models is only present in the {{srcbranchdir\|ksenija2\|}} branch of ASCEND; we haven't yet included in the trunk code.		Note that currently the required solver code to run these models is only present in the {{srcbranchdir\|ksenija2\|}} branch of ASCEND; we haven't yet included in the trunk code.

			For more detail see {{srcbranch\|ksenija2\|doc/howto-events.lyx}} (in LyX format)

	[[Category:Syntax]]		[[Category:Syntax]]
	[[Category:Documentation]]		[[Category:Documentation]]

Jpye at 08:51, 24 March 2015

2015-03-24T08:51:44Z

← Older revision		Revision as of 08:51, 24 March 2015
Line 1:		Line 1:
	{{experimental}}		{{experimental}}
	The '''EVENT''' statement in ASCEND is used to declare named events in a [[dynamic modelling\|dynamic system model]]. The event is triggered by an inequality going from being false to being true. The syntax is		The '''EVENT''' statement in ASCEND is used to declare named events in a [[dynamic modelling\|dynamic system model]]. The event is triggered by an inequality going from being false to being true. This is part of our work to support [[integration of conditional models]]. The syntax is

	<source lang=a4c>		<source lang=a4c>

Jpye: /* Examples */

2015-03-24T08:51:05Z

Examples

← Older revision		Revision as of 08:51, 24 March 2015
Line 43:		Line 43:
	The best starter example is the {{srcbranch\|ksenija2\|models/ksenija/bball_event3.a4c}} bouncing-ball model. It is complete and solves well.		The best starter example is the {{srcbranch\|ksenija2\|models/ksenija/bball_event3.a4c}} bouncing-ball model. It is complete and solves well.

	Another nice easy example is the {{~~srcbrnach~~\|ksenija2\|models/ksenija/thermostat.a4c}} thermostat model.		Another nice easy example is the {{srcbranch\|ksenija2\|models/ksenija/thermostat.a4c}} thermostat model.

	Note that currently the required solver code to run these models is only present in the {{srcbranchdir\|ksenija2\|}} branch of ASCEND; we haven't yet included in the trunk code.		Note that currently the required solver code to run these models is only present in the {{srcbranchdir\|ksenija2\|}} branch of ASCEND; we haven't yet included in the trunk code.

Jpye: /* pre(x) */

2015-03-24T08:50:27Z

pre(x)

← Older revision		Revision as of 08:50, 24 March 2015
Line 31:		Line 31:
	Special 'previous value' variables can be declared on an as-needed basis. These 'pre(x)' variables must be explicitly declared before they will be allowed to exist. This is done using the PREVIOUS statement. After being declared, event equations can be used that refer to the declared variable.		Special 'previous value' variables can be declared on an as-needed basis. These 'pre(x)' variables must be explicitly declared before they will be allowed to exist. This is done using the PREVIOUS statement. After being declared, event equations can be used that refer to the declared variable.

	<~~src~~ lang=a4c>		<source lang=a4c>
	(* 'bouncing' of a ball: the velocity reverses *)		(* 'bouncing' of a ball: the velocity reverses *)
	PREVIOUS v;		PREVIOUS v;
	rel1: v = -pre(v)*0.9;		rel1: v = -pre(v)*0.9;
	</~~src~~>		</source>

	A 'pre(x)' variable will always be fixed, and the solver will only bother to change its value at the boundaries. If the user tries to FIX/FREE/assign a value to a 'pre(x)' variable, the changes will be ignored and lost as soon as IDA arrives at a boundary that it needs to solve.		A 'pre(x)' variable will always be fixed, and the solver will only bother to change its value at the boundaries. If the user tries to FIX/FREE/assign a value to a 'pre(x)' variable, the changes will be ignored and lost as soon as IDA arrives at a boundary that it needs to solve.

Jpye: Created page with "{{experimental}} The '''EVENT''' statement in ASCEND is used to declare named events in a dynamic system model. The event is triggered by an inequality g..."

2015-03-24T08:50:12Z

Created page with "{{experimental}} The '''EVENT''' statement in ASCEND is used to declare named events in a dynamic system model. The event is triggered by an inequality g..."

New page

{{experimental}}
The '''EVENT''' statement in ASCEND is used to declare named events in a [[dynamic modelling|dynamic system model]]. The event is triggered by an inequality going from being false to being true. The syntax is

<source lang=a4c>
event_name: EVENT(bool1)
CASE TRUE: USE rel1;
CASE FALSE: USE rel2;
OTHERWISE: USE rel3;
END EVENT;
</source>

The boolean variable <tt>bool1</tt> would be defined using our normal [[conditional modelling]] syntax. Normally, a [[CONDITIONAL]] statement is required to express the condition as an inequality with real-valued variables, and then optionally there can be some boolean logic, and then a single boolean variable is used to trigger the event.

The <tt>CASE TRUE</tt> applies when the value of <tt>bool1</tt> changes from <tt>FALSE</tt> to <tt>TRUE</tt>.

The <tt>CASE FALSE</tt> case applies when the value of <tt>bool1</tt> changes from <tt>TRUE</tt> to <tt>FALSE</tt>.

The <tt>OTHERWISE</tt> case requires some careful explanation. Any relations listed here are '''''excluded''''' from the system before solving the boundary problem.

===How events are handled===

# A change in a boolean variable associated with an <tt>EVENT</tt> is detected by our solver (at present: [[IDA]])
# Any relations named by [[USE]] statements in the <tt>OTHERWISE</tt> clause of the <tt>EVENT</tt> are removed from the system model (de-activated).
# Any relations named by [[USE]] statements in the active <tt>CASE</tt> are added to the system model (activated).
# Any [[METHOD]] that belongs in the same model as the [[EVENT]] and which carries the same name as the event (<tt>event_name</tt> in the above example is run. Normally these methods are used to [[FIX]]/[[FREE]] variables to assist in the solution of the boundary equations included via the [[USE]] statements in the [[EVENT]].
# The [[QRSlv]] solver is run on the model, in order to solve the [[EVENT]] equations. Currently, the whole system model is solved by QRSlv in this way. Perhaps there is a faster/better way to do this with a reduced problem being passed to QRSlv.
# Any [[METHOD]] carrying the name <tt>''event_name''_end</tt> is run. This would normally allow the model to be restored to its former condition, to allow integration to continue.

===pre(x)===

Special 'previous value' variables can be declared on an as-needed basis. These 'pre(x)' variables must be explicitly declared before they will be allowed to exist. This is done using the PREVIOUS statement. After being declared, event equations can be used that refer to the declared variable.

<src lang=a4c>
(* 'bouncing' of a ball: the velocity reverses *)
PREVIOUS v;
rel1: v = -pre(v)*0.9;
</src>

A 'pre(x)' variable will always be fixed, and the solver will only bother to change its value at the boundaries. If the user tries to FIX/FREE/assign a value to a 'pre(x)' variable, the changes will be ignored and lost as soon as IDA arrives at a boundary that it needs to solve.

=== Examples ===

The best starter example is the {{srcbranch|ksenija2|models/ksenija/bball_event3.a4c}} bouncing-ball model. It is complete and solves well.

Another nice easy example is the {{srcbrnach|ksenija2|models/ksenija/thermostat.a4c}} thermostat model.

Note that currently the required solver code to run these models is only present in the {{srcbranchdir|ksenija2|}} branch of ASCEND; we haven't yet included in the trunk code.

[[Category:Syntax]]
[[Category:Documentation]]