Talk:Event handling - Revision history

BenAllan: /* Initial condition problems */

2012-02-15T20:07:38Z

Initial condition problems

← Older revision		Revision as of 20:07, 15 February 2012
Line 41:		Line 41:
	The ascend language cannot even name the state of all the variables in the model at a given value of the independent variable. I'm not particularly aware of any small modeling language which allows you to name the solution of the model at arbitrary times. Several quick-hack languages like gproms/modelica allow you to handle implicitly defined values near 'events'. A more general solution is highly desirable and with the cost of computer memory being essentially zero at this point, there is no reason (any longer) to exclude naming states in the modeling language.		The ascend language cannot even name the state of all the variables in the model at a given value of the independent variable. I'm not particularly aware of any small modeling language which allows you to name the solution of the model at arbitrary times. Several quick-hack languages like gproms/modelica allow you to handle implicitly defined values near 'events'. A more general solution is highly desirable and with the cost of computer memory being essentially zero at this point, there is no reason (any longer) to exclude naming states in the modeling language.

			Ben
	----		----

BenAllan: /* Initial condition problems */

2012-02-15T20:04:36Z

Initial condition problems

← Older revision		Revision as of 20:04, 15 February 2012
Line 30:		Line 30:

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

			----
			Syntactic/semantic background to inform our design process:

			An underused feature in ascend is that equations, boundaries, and I think even whens
			all have names and subatomic children(flags), which can be used.

			The current declarative language is focused entirely on declaring an algebraic mathematical description with no time or space dependence. All handling of these variations requires discretization over the domain of the independent variable by either the model statement itself (a boundary value formulation) or by the solver (initial value formulation).

			The ascend language cannot even name the state of all the variables in the model at a given value of the independent variable. I'm not particularly aware of any small modeling language which allows you to name the solution of the model at arbitrary times. Several quick-hack languages like gproms/modelica allow you to handle implicitly defined values near 'events'. A more general solution is highly desirable and with the cost of computer memory being essentially zero at this point, there is no reason (any longer) to exclude naming states in the modeling language.

			----

	== Proposal 1: a quick hack ==		== Proposal 1: a quick hack ==

Jpye: /* Proposal 2: a better approach */

2012-02-15T19:37:17Z

Proposal 2: a better approach

← Older revision		Revision as of 19:37, 15 February 2012
Line 87:		Line 87:

	4. Add the 'pre' so that REINIT statemnts can access previous values of other variables. This would be some kind of callback to the Integrator.		4. Add the 'pre' so that REINIT statemnts can access previous values of other variables. This would be some kind of callback to the Integrator.

			== Proposal 3: EVENT statement ==

			We need to put the event handling separate to the WHEN statements. So for a bouncing ball model,

			<source lang=a4c>
			EVENT x == 0
			REINIT xvel :== -pre(xvel);
			END EVENT;
			</source>

			The 'EVENT' statement needs to fire any time that the boolean expression ''was'' previously false, and ''now becomes'' true, i.e. a rising edge. So, what is the difference between the above and the following?

			<source lang=a4c>
			EVENT x >= 0
			REINIT xvel :== -pre(xvel);
			END EVENT;
			</source>

			Not sure if there is a difference? Need to clarify.

			== Proposal 4: EVENT statement with RUN ==

			This is a modification of Proposal 1.

			<source lang=a4c>
			EVENT x == 0
			RUN mybouncemethod;
			END EVENT;
			</source>

			We could implement this without having to first add support for definition of ICPs, which Proposal 3 definitely requires. Hence this is a quick hack that would let us keep working on the solver algorithms, and let the language features catch up afterwards.

Jpye: /* Proposal 1: a quick hack */

2012-02-15T19:29:20Z

Proposal 1: a quick hack

← Older revision		Revision as of 19:29, 15 February 2012
Line 50:		Line 50:

	4. Run a general <tt>continue</tt> method to restore the DAE problem, the proceed with IDA integration until the next boundary.		4. Run a general <tt>continue</tt> method to restore the DAE problem, the proceed with IDA integration until the next boundary.

			''This approach is flawed because regions are really not the same as events; we should put the 'RUN' statement in the above inside some other kind of statement -- Proposal 4 below.''

	== Proposal 2: a better approach ==		== Proposal 2: a better approach ==

Jpye: /* Proposal 2: a better approach */

2012-02-14T23:35:09Z

Proposal 2: a better approach

← Older revision		Revision as of 23:35, 14 February 2012
Line 74:		Line 74:

	3. Modify WHEN statement to support reinitialisation of state variables before the ICP is solved. The problem here is in making sure we can generate consistent ICPs. Do these reinitialisations replace INITIAL equations, or simple reassign values, independently of the ICP solution?		3. Modify WHEN statement to support reinitialisation of state variables before the ICP is solved. The problem here is in making sure we can generate consistent ICPs. Do these reinitialisations replace INITIAL equations, or simple reassign values, independently of the ICP solution?

			<source lang=a4c>
	WHEN y_is_zero		WHEN y_is_zero
	CASE TRUE:		CASE TRUE:
	REINIT vel :== -pre(vel);		REINIT vel :== -pre(vel);
	END WHEN;		END WHEN;
			</source>

	In Modelica, this ~~FIX g~~.~~.. syntax is~~		Need to understand whether we need equivalents of Modelica's 'when-equation' as well as this 'reinit' thing.

	4. Add the 'pre' so that REINIT statemnts can access previous values of other variables. This would be some kind of callback to the Integrator.		4. Add the 'pre' so that REINIT statemnts can access previous values of other variables. This would be some kind of callback to the Integrator.

Jpye at 23:31, 14 February 2012

2012-02-14T23:31:27Z

@@ Line 3: / Line 3: @@
 == 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.
+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 statements 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.
@@ Line 30: / Line 30: @@
 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]].

Jpye at 21:17, 14 February 2012

2012-02-14T21:17:01Z

← Older revision		Revision as of 21:17, 14 February 2012
Line 12:		Line 12:

	[[User:Jpye\|Jpye]] 10:55, 11 February 2012 (EST)		[[User:Jpye\|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 <tt>initcond</tt> we could prepare the initial condition problem, and in a method <tt>continue</tt> we could restore the DAE problem. Somewhere inside IDA, then, we would detect a boundary and [[RUN]] <tt>initcond</tt>, then run [[QRSlv]], then run <tt>continue</tt>, 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]].

Jpye: Created page with "''Please add new comments below with a '''==heading==''' and signed beneath using '''~~~~'''. If responding to an earlier comment, prefix you..."

2012-02-10T23:55:36Z

Created page with "''Please add new comments below with a '''<nowiki>==heading==</nowiki>''' and signed beneath using '''<nowiki>~~~~</nowiki>'''. If responding to an earlier comment, prefix you..."

New page

''Please add new comments below with a '''<nowiki>==heading==</nowiki>''' and signed beneath using '''<nowiki>~~~~</nowiki>'''. 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.

[[User:Jpye|Jpye]] 10:55, 11 February 2012 (EST)