User:Ksenija - Revision history

Jpye at 02:14, 5 March 2015

2015-03-05T02:14:37Z

← Older revision		Revision as of 02:14, 5 March 2015
Line 8:		Line 8:
	==GSOC2013==		==GSOC2013==

	===Possible ways of improvement of our conditional syntax.===		===Possible ways of improvement of our conditional syntax===

	The first possible modification is defining the condition right in the event statement:		The first possible modification is defining the condition right in the event statement:
Line 35:		Line 35:
	we do this for events, the same should be done for whens, I think.		we do this for events, the same should be done for whens, I think.

	===Example models.===		===Example models===

	{{srcbranch\|ksenija2\|models/ksenija/test_event2.a4c}} - the simplest model with events. When x crosses some given values, it increases discontinuously, and then integration continues in a usual way.		{{srcbranch\|ksenija2\|models/ksenija/test_event2.a4c}} - the simplest model with events. When x crosses some given values, it increases discontinuously, and then integration continues in a usual way.
Line 61:		Line 61:
	{{srcbranch\|ksenija2\|models/ksenija/clock.a4c}} - a model of the Galileo-Huygens clock from Ju.I.Neimark, "Mathematical models in natural science and engineering".		{{srcbranch\|ksenija2\|models/ksenija/clock.a4c}} - a model of the Galileo-Huygens clock from Ju.I.Neimark, "Mathematical models in natural science and engineering".

	===Project plan.===		===Project plan===

	* Community bonding period		* Community bonding period
Line 83:		Line 83:
	** September 16 – September 23. Final testing, writing documentation.		** September 16 – September 23. Final testing, writing documentation.

	===Weekly reports.===		===Weekly reports===

	'''September, 09 - September, 15.'''		'''September, 09 - September, 15.'''
Line 272:		Line 272:
	* wrote code for destroying event instances.		* wrote code for destroying event instances.

	===Final report.===		===Final report===

	'''Event syntax.'''		'''Event syntax.'''
Line 332:		Line 332:
	</source>		</source>

	==Variable structure modeling in ASCEND. Plan for summer of code 2013 and my final-year project.==		==Variable structure modeling in ASCEND. Plan for summer of code 2013 and my final-year project==

	===The goal.===		===The goal===

	====General description of the problem.====		====General description of the problem====

	Currently ASCEND solves problems with region switching behavior pretty well. But it still doesn't have good means for describing and solving models with changes happening exactly at the boundaries (which may also be one-sided - e. g. hysteresis). These may be solving some boundary equations or assigning values to some variables.		Currently ASCEND solves problems with region switching behavior pretty well. But it still doesn't have good means for describing and solving models with changes happening exactly at the boundaries (which may also be one-sided - e. g. hysteresis). These may be solving some boundary equations or assigning values to some variables.

	====Example problems.====		====Example problems====

	Some example problems are given on this page: [[Event handling]]. Some more interesting examples may concern encoding analog signals into digital signals (see [https://en.wikipedia.org/wiki/Delta-sigma_modulation Delta-sigma modulation] on Wikipedia). I am still searching for more examples.		Some example problems are given on this page: [[Event handling]]. Some more interesting examples may concern encoding analog signals into digital signals (see [https://en.wikipedia.org/wiki/Delta-sigma_modulation Delta-sigma modulation] on Wikipedia). I am still searching for more examples.

	===Syntax.===		===Syntax===

	====Requirements.====		====Requirements====

	The syntax should enable the user to 1) state which actions should be performed at the boundary 2) associate them with an exact boundary 3) state in which direction the boundary should work (for one-sided boundaries). And, as usual, the syntax should be unambiguous, flexible and clear.		The syntax should enable the user to 1) state which actions should be performed at the boundary 2) associate them with an exact boundary 3) state in which direction the boundary should work (for one-sided boundaries). And, as usual, the syntax should be unambiguous, flexible and clear.
Line 378:		Line 378:
	</source>		</source>

	===Implementation.===		===Implementation===

	ASCEND is efficient with large models, and this work shouldn't break this characteristic. So we need the code to be fast and efficient.		ASCEND is efficient with large models, and this work shouldn't break this characteristic. So we need the code to be fast and efficient.
Line 388:		Line 388:
	==GSOC2012==		==GSOC2012==

	===Project description.===		===Project description===

	The goal of the project is to add new syntax for derivatives which will improve the capabilities of ASCEND in dynamic modelling and increase usability. Currently defining derivatives in ASCEND is not enough intuitive and convenient: for the user the process consists of, firstly, defining usual variables by using the IS_A statement, and then stating that one variable is the derivative of the other. With the new syntax the derivative of x in respect to t would look like der(x,t) and by using this expression new variables would be created automatically. Corresponding changes to the solver API would need to be made.		The goal of the project is to add new syntax for derivatives which will improve the capabilities of ASCEND in dynamic modelling and increase usability. Currently defining derivatives in ASCEND is not enough intuitive and convenient: for the user the process consists of, firstly, defining usual variables by using the IS_A statement, and then stating that one variable is the derivative of the other. With the new syntax the derivative of x in respect to t would look like der(x,t) and by using this expression new variables would be created automatically. Corresponding changes to the solver API would need to be made.

	=== Project plan. ===		=== Project plan ===

	* Parser changes		* Parser changes
Line 419:		Line 419:
	# '''Add DerInfo to RealAtomInstance.''' I will need to think about the implementation.		# '''Add DerInfo to RealAtomInstance.''' I will need to think about the implementation.

	'''June, 10.'''		'''June, 10'''

	# '''Finish changing the functions from typedef.c''' so that they would use the new names.		# '''Finish changing the functions from typedef.c''' so that they would use the new names.
Line 426:		Line 426:
	# '''Change the instantiator''' in order to process new names.		# '''Change the instantiator''' in order to process new names.

	'''July, 13.'''		'''July, 13'''

	# '''Change integrator_find_indep_var''': with the use of the diffvars code it could find the independent variable in a much simpler way.		# '''Change integrator_find_indep_var''': with the use of the diffvars code it could find the independent variable in a much simpler way.
Line 432:		Line 432:
	# Think about '''some more possible refinements''' of problem analysis?		# Think about '''some more possible refinements''' of problem analysis?

	===Weekly reports.===		===Weekly reports===

	'''May, 21 - May, 27.'''		'''May, 21 - May, 27.'''
Line 522:		Line 522:
	* Added more comments.		* Added more comments.

	===Final report.===		===Final report===

	Summing up the result of the work, the following goals have been achieved during this summer:		Summing up the result of the work, the following goals have been achieved during this summer:
Line 583:		Line 583:
	where <tt>M</tt> is a simulation Python object (see {{srcbranch\|ksenija\|models/ksenija/example.py}})		where <tt>M</tt> is a simulation Python object (see {{srcbranch\|ksenija\|models/ksenija/example.py}})

	== Ideas for the new syntax for models with hysteresis.==		== Ideas for the new syntax for models with hysteresis==

	The difficulty which I came across when trying to write some models with hysteresis was that I couldn't set the state of the system, on which its behavior depends. It should change with time, but the WHEN statement is not suited for this, I think.		The difficulty which I came across when trying to write some models with hysteresis was that I couldn't set the state of the system, on which its behavior depends. It should change with time, but the WHEN statement is not suited for this, I think.

Jpye at 00:59, 2 November 2013

2013-11-02T00:59:43Z

← Older revision		Revision as of 00:59, 2 November 2013
Line 635:		Line 635:
	[[Category:ASCEND Contributors]]		[[Category:ASCEND Contributors]]
	[[Category:GSOC2012]]		[[Category:GSOC2012]]
			[[Category:GSOC2013]]

Ksenija at 15:05, 23 September 2013

2013-09-23T15:05:40Z

← Older revision		Revision as of 15:05, 23 September 2013
Line 272:		Line 272:
	* wrote code for destroying event instances.		* wrote code for destroying event instances.

			===Final report.===

			'''Event syntax.'''

			New event syntax has been implemented:

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

			bvar is a boolean variable, rel1 and rel2 are relations or logrelations or submodels. When bvar changes its value from TRUE to FALSE, the corresponding case is activated. Then the model is solved with LRSlv and QRSlv, and after that rel1 is deactivated.

			rel2 is switched on during the continious-time frame or at those boundaries at which this event is not triggered.

			If the model contains methods with names event_name and/or event_name_end, these methods will be called before and after solving the system at the boundary correspondingly.

			'''New boundary crossing algorithm.'''

			Here is the algorithm of the boundary crossing function:

			*For each boundary:
			**If this boundary has been crossed:
			***Has it been crossed twice in one direction?
			***No:
			****change the boundary flag.
			***Yes:
			****if it has not been done yet, save current values of discrete variables.
			****Change the boundary flag.
			****Call the logical solver (it could be called not it this loop, but it would make the code more complicated and it would not make the algorithm much more efficient because double crossing of two boundaries at the same time is rather improbable. In all other cases there is no difference.)
			****Change the boundary flag one more time (so the value of the flag will be the same as at the beginning of the function.
			*Call the logical solver.
			*If there has been a double crossing, set the correct previous values for those variables for which it is necessary.
			*Have some discrete variables changed?
			**No:
			***reset the boundary flags, continue integration.
			**Yes:
			***reanalyze the system: switch on the correct regions (WHEN cases), call the methods associated with events, switch on the boundary equations.
			***Solve the system with QRSlv.
			***Check if some boundaries have been crossed as a result of solving the system with QRSlv. Set the correct boundary flags.
			***Solve the system with LRSlv.
			***If some discrete variables have changed, repeat from reanalyzing the system.
			***Reanalyze the system: switch on the correct regions, call the methods associated with events, switch off the boundary equations.
			***Reset the boundary flags, continue integration.

			Here boundaries are data structures corresponding to the relations declared inside CONDITIONAL.
			Boundary flags can have two values: 0 and 1. If a flag is 0 (or 1), this means that when solving the system of logical equations the statement: SATISFIED(cond_rel), where cond_rel in the boundary condition, will return 0(or 1). The flags are set at the beginning of integration and changed at boundary crossings.

			'''Pre() syntax.'''

			The aim of pre() variables is to access the value of the variable before the boundary. Pre() variables are FIXed and change their values only at boundaries. An example:

			<source lang=a4c>
			y IS_A solver_var;
			PREVIOUS y;
			bnd_eq: y = pre(y)*0.9;
			</source>

	==Variable structure modeling in ASCEND. Plan for summer of code 2013 and my final-year project.==		==Variable structure modeling in ASCEND. Plan for summer of code 2013 and my final-year project.==

Ksenija at 14:19, 20 September 2013

2013-09-20T14:19:27Z

← Older revision		Revision as of 14:19, 20 September 2013
Line 84:		Line 84:

	===Weekly reports.===		===Weekly reports.===

			'''September, 09 - September, 15.'''

			This week I have been working on GUI features.

			The points where an event was triggered are marked red on the plot. Plots for each event can also be created showing how the variable changes at each step of processing the system at the boundary.

			[[File:Plot_events1.png\|thumb\|none\|Several equal values of the independent variable mean that there was an event]]

			[[File:Plot_events2.png\|thumb\|none\|Red points indicate events]]

			[[File:Plot_events3.png\|thumb\|none\|The user may choose an event and plot the values found at the chosen boundary]]


	'''September, 02 - September, 08.'''		'''September, 02 - September, 08.'''

Ksenija at 13:26, 20 September 2013

2013-09-20T13:26:25Z

← Older revision		Revision as of 13:26, 20 September 2013
Line 39:		Line 39:
	{{srcbranch\|ksenija2\|models/ksenija/test_event2.a4c}} - the simplest model with events. When x crosses some given values, it increases discontinuously, and then integration continues in a usual way.		{{srcbranch\|ksenija2\|models/ksenija/test_event2.a4c}} - the simplest model with events. When x crosses some given values, it increases discontinuously, and then integration continues in a usual way.

	{{srcbranch\|ksenija2\|models/ksenija/thermostat.a4c}} - a model of a thermostat.		{{srcbranch\|ksenija2\|models/ksenija/thermostat.a4c}} - a model of a thermostat. The heater is swithed on when the temperature rises above 23 degrees and is switched on when the temperature falls below 19 degrees.

	{{srcbranch\|ksenija2\|models/ksenija/bball_event~~.a4c}}, {{srcbranch\|ksenija2\|models/ksenija/bball_event2~~.a4c}} - a bouncing ball. When it hits the ground, it instantly changes its speed. Some problems concerning this models still remain. First, I don't know what to do with the system not being square. Adding and subtracting y is definitely not a good idea. Second, when the ball almost rests on the floor it is hard to process all boundary crossings correctly.		{{srcbranch\|ksenija2\|models/ksenija/bball_event.a4c}} - a bouncing ball. When it hits the ground, it instantly changes its speed.

	{{srcbranch\|ksenija2\|models/ksenija/bball_event3.a4c}} - ~~the Modelica~~ version of the bouncing ball model.		{{srcbranch\|ksenija2\|models/ksenija/bball_event3.a4c}} - another version of the bouncing ball model.

	{{srcbranch\|ksenija2\|models/ksenija/hysteron_event.a4c}} - a model of a simple hysteron. This is an example from Krasnosel'skii, M.; Pokrovskii, A.. Systems with Hysteresis. A piston is moving inside a cylinder, the position of the piston is the input u, the position of the cylinder’s right end is the output x.		{{srcbranch\|ksenija2\|models/ksenija/hysteron_event.a4c}} - a model of a simple hysteron. This is an example from Krasnosel'skii, M.; Pokrovskii, A.. Systems with Hysteresis. A piston is moving inside a cylinder, the position of the piston is the input u, the position of the cylinder’s right end is the output x.

			[[File:hysteron.png\|thumb\|none\|A sketch of the cilinder]]


	{{srcbranch\|ksenija2\|models/ksenija/hysteron_event2.a4c}} - one more model of a hysteron. This is an example from Krasnosel'skii, M.; Pokrovskii, A.. Systems with Hysteresis.		{{srcbranch\|ksenija2\|models/ksenija/hysteron_event2.a4c}} - one more model of a hysteron. This is an example from Krasnosel'skii, M.; Pokrovskii, A.. Systems with Hysteresis.
Line 57:		Line 60:

	{{srcbranch\|ksenija2\|models/ksenija/clock.a4c}} - a model of the Galileo-Huygens clock from Ju.I.Neimark, "Mathematical models in natural science and engineering".		{{srcbranch\|ksenija2\|models/ksenija/clock.a4c}} - a model of the Galileo-Huygens clock from Ju.I.Neimark, "Mathematical models in natural science and engineering".

	~~'''Models which are not yet written:'''~~

	* A vessel with a sliding mode.
	* Some other models?

	===Project plan.===		===Project plan.===

Ksenija at 16:05, 17 September 2013

2013-09-17T16:05:36Z

← Older revision		Revision as of 16:05, 17 September 2013
Line 7:		Line 7:

	==GSOC2013==		==GSOC2013==

	~~===Todos for the rest of the summer.===~~

	* 03.08 - 11.08 - add the pre() syntax. (done)
	* 12.08 - 18.08 - test the pre() syntax. Add pre functionality to the solver. Update the models. (done)
	* 19.08 - 25.08 - think about possible ways of making event handling more efficient.
	* 26.08 - 01.09 - test the event handling code, fix bugs.
	* 02.09 - 16.09 - add automatic boundary emission.
	* 17.09 - 23.09 - write documentation.

	~~After GSOC:~~

	* Check one more time the code for the der syntax, may be improve some parts of it.
	* Write and study with the help of ASCEND complex models with interesting mathematics under the guidance of my university supervisor Dr. Shananin.

	===Possible ways of improvement of our conditional syntax.===		===Possible ways of improvement of our conditional syntax.===

Ksenija at 17:15, 9 September 2013

2013-09-09T17:15:10Z

← Older revision		Revision as of 17:15, 9 September 2013
Line 100:		Line 100:

	===Weekly reports.===		===Weekly reports.===

			'''September, 02 - September, 08.'''

			* Added a model of the Huygens pendulum clock: {{srcbranch\|ksenija2\|models/ksenija/clock.a4c}}

			[[File:huygens_clock.png\|thumb\|none\|The phase plane of the Huygens clock model]]

			* Changed cond_config.c so that when the OTHERWISE case of the event is switched on at the boundary, the method associated with the event is not called.

			* Switched off event analyzing in configure_conditional_problem (which is called during problem building). The events are analyzed later, so there is no need for that call.

			* Set the event_active flags FALSE before analyzing the system at the boundary.

			* Report errors if the analysis of the system after solving the boundary equations fails.

			* Until this week the integrator was reinitialized after each root found. This didn't influence the speed much, but for some models this reinitialization could lead to incorrect solutions. Without it when solving the hysteron model IDA reported an error because of two very close roots.

			To solve this problem I changed the boundary crossing code. Now after solving the boundary equations for the first time it is checked if values of some discrete variables have changed. If yes, the system is analyzed one more time. These actions are repeated in a loop until no events are called or no discrete variables change their values. So the case when an event causes another event is handled properly and no unneeded reinitialization of the integrator is done.

			* Thought about boundary emission and read about the implementation of this feature in Modelica and Mathematica.

			* I decided to spend the last week of GSOC on improving the plotting tools for models with events. There are several points at each boundary which can be useful for debugging of the models, and I am going to plot them in such a way that the user would be able to see those points and distinguish them from other points.

	'''August, 26 - September, 1.'''		'''August, 26 - September, 1.'''

Ksenija at 07:57, 4 September 2013

2013-09-04T07:57:40Z

← Older revision		Revision as of 07:57, 4 September 2013
Line 68:		Line 68:

	[[File:vessel_with_siphon.png\|thumb\|none\|A sketch of the vessel]]		[[File:vessel_with_siphon.png\|thumb\|none\|A sketch of the vessel]]


			{{srcbranch\|ksenija2\|models/ksenija/clock.a4c}} - a model of the Galileo-Huygens clock from Ju.I.Neimark, "Mathematical models in natural science and engineering".

	'''Models which are not yet written:'''		'''Models which are not yet written:'''

Ksenija at 07:37, 4 September 2013

2013-09-04T07:37:05Z

← Older revision		Revision as of 07:37, 4 September 2013
Line 97:		Line 97:

	===Weekly reports.===		===Weekly reports.===

			'''August, 26 - September, 1.'''

			* Removed some unneeded code.

			* Changed the ida_cross_boundary function so that previous of discrete variables values are now corrected only if a double crossing has been detected.

			* Added a warning message which is shown if relation instances are referenced by both events and whens.

			* Set the flags indicating if there is a method associated with the event. If there isn't, the search for the method is skipped.

			* Changed the integrator_ida_solve function crossing one and the same boundary twice in one direction is avoided not only if IDASolve is recalled up to the same tindex (which happens if the root is found far from the desired output t), but also if the timestep is advanced.

	'''August, 19 - August, 25.'''		'''August, 19 - August, 25.'''

Ksenija at 06:45, 30 August 2013

2013-08-30T06:45:49Z

← Older revision		Revision as of 06:45, 30 August 2013
Line 13:		Line 13:
	* 12.08 - 18.08 - test the pre() syntax. Add pre functionality to the solver. Update the models. (done)		* 12.08 - 18.08 - test the pre() syntax. Add pre functionality to the solver. Update the models. (done)
	* 19.08 - 25.08 - think about possible ways of making event handling more efficient.		* 19.08 - 25.08 - think about possible ways of making event handling more efficient.
	* 26.08 - 16.09 - test the event handling code, fix bugs.		* 26.08 - 01.09 - test the event handling code, fix bugs.
			* 02.09 - 16.09 - add automatic boundary emission.
	* 17.09 - 23.09 - write documentation.		* 17.09 - 23.09 - write documentation.

← Older revision		Revision as of 13:26, 20 September 2013
Line 39:		Line 39:
	{{srcbranch\|ksenija2\|models/ksenija/test_event2.a4c}} - the simplest model with events. When x crosses some given values, it increases discontinuously, and then integration continues in a usual way.		{{srcbranch\|ksenija2\|models/ksenija/test_event2.a4c}} - the simplest model with events. When x crosses some given values, it increases discontinuously, and then integration continues in a usual way.

	{{srcbranch\|ksenija2\|models/ksenija/thermostat.a4c}} - a model of a thermostat.		{{srcbranch\|ksenija2\|models/ksenija/thermostat.a4c}} - a model of a thermostat. The heater is swithed on when the temperature rises above 23 degrees and is switched on when the temperature falls below 19 degrees.

	{{srcbranch\|ksenija2\|models/ksenija/bball_event~~.a4c}}, {{srcbranch\|ksenija2\|models/ksenija/bball_event2~~.a4c}} - a bouncing ball. When it hits the ground, it instantly changes its speed. Some problems concerning this models still remain. First, I don't know what to do with the system not being square. Adding and subtracting y is definitely not a good idea. Second, when the ball almost rests on the floor it is hard to process all boundary crossings correctly.		{{srcbranch\|ksenija2\|models/ksenija/bball_event.a4c}} - a bouncing ball. When it hits the ground, it instantly changes its speed.

	{{srcbranch\|ksenija2\|models/ksenija/bball_event3.a4c}} - ~~the Modelica~~ version of the bouncing ball model.		{{srcbranch\|ksenija2\|models/ksenija/bball_event3.a4c}} - another version of the bouncing ball model.

	{{srcbranch\|ksenija2\|models/ksenija/hysteron_event.a4c}} - a model of a simple hysteron. This is an example from Krasnosel'skii, M.; Pokrovskii, A.. Systems with Hysteresis. A piston is moving inside a cylinder, the position of the piston is the input u, the position of the cylinder’s right end is the output x.		{{srcbranch\|ksenija2\|models/ksenija/hysteron_event.a4c}} - a model of a simple hysteron. This is an example from Krasnosel'skii, M.; Pokrovskii, A.. Systems with Hysteresis. A piston is moving inside a cylinder, the position of the piston is the input u, the position of the cylinder’s right end is the output x.

			[[File:hysteron.png\|thumb\|none\|A sketch of the cilinder]]


	{{srcbranch\|ksenija2\|models/ksenija/hysteron_event2.a4c}} - one more model of a hysteron. This is an example from Krasnosel'skii, M.; Pokrovskii, A.. Systems with Hysteresis.		{{srcbranch\|ksenija2\|models/ksenija/hysteron_event2.a4c}} - one more model of a hysteron. This is an example from Krasnosel'skii, M.; Pokrovskii, A.. Systems with Hysteresis.
Line 57:		Line 60:

	{{srcbranch\|ksenija2\|models/ksenija/clock.a4c}} - a model of the Galileo-Huygens clock from Ju.I.Neimark, "Mathematical models in natural science and engineering".		{{srcbranch\|ksenija2\|models/ksenija/clock.a4c}} - a model of the Galileo-Huygens clock from Ju.I.Neimark, "Mathematical models in natural science and engineering".

	~~'''Models which are not yet written:'''~~

	* A vessel with a sliding mode.
	* Some other models?

	===Project plan.===		===Project plan.===