User:Hugo - Revision history

Mike: add to contributor category

2018-01-31T11:02:23Z

add to contributor category

← Older revision		Revision as of 11:02, 31 January 2018
Line 106:		Line 106:

	[[Category:GSOC2016]]		[[Category:GSOC2016]]
			[[Category:ASCEND Contributors]]

Hugo: More prominent link

2016-08-22T05:06:49Z

Hugo: update page for the GSOC final evaluation

2016-08-22T05:03:58Z

update page for the GSOC final evaluation

← Older revision		Revision as of 05:03, 22 August 2016
Line 1:		Line 1:
	I'm Hugo Gualandi, and am currently pursuing a PhD at [http://www.lua.inf.puc-rio.br/ PUC-Rio university], focusing on programming languages~~. For [[GSOC2016]], I'm trying to improve ASCEND's conditional modeling syntax~~.		I'm Hugo Gualandi, and am currently pursuing a PhD at [http://www.lua.inf.puc-rio.br/ PUC-Rio university], focusing on programming languages.

	== ~~Goal of~~ the ~~Project~~ ==		== GSOC 2016 Project: Improvements to the Conditional Modeling Syntax ==

	The goal of this project is to improve the usability of dynamic and conditional modeling in ASCEND. This includes:		The goal of my 2016 Summer Of Code project was to improve ASCEND's conditional modelling syntax. The first thing I did was to study the current state of ASCEND's conditional modeling and identify some ways in which the current modeling syntax and semantics could be improved. My findings are documented in the [[#Proposed syntax changes]] section.

			My most significant contribution during this project was to implement an experimental alternative parser for the ASCEND modeling language that allows a faster rate of experimentation for new syntactic features compared to the existing ASCEND parser. I documented what this parser does and how to use it in its own wiki page: [[OcamlParser]].

			What is left to is leverage the new parser to experiment with the new designs for the conditional syntax and then, after verifying that they work well, implement the required changes in ASCEND's main compiler.

			== Proposed syntax changes ==

			The main goal of this project was to improve the usability of dynamic and conditional modeling in ASCEND. This includes:

	1) Reducing redundancy in the specification		1) Reducing redundancy in the specification
Line 13:		Line 21:
	* I believe that the key to improving this is a better way to specify initial conditions in models.		* I believe that the key to improving this is a better way to specify initial conditions in models.

	So far, I have identified many easy places to improve the language regarding point #1. Point #2 is something that ~~I still working on though~~...		So far, I have identified many easy places to improve the language regarding point #1. Point #2 is something that ended up being harder than expected. Many of my proposed changes were inspired by the [https://www.modelica.org/ Modelica] system and I would highly recommend checking that out for comparison.

			=== Easy redundancy reduction ===
	== Easy redundancy reduction ==

	1) We could infer the PREVIOUS and DERIVATIVE OF declarations.		1) We could infer the PREVIOUS and DERIVATIVE OF declarations.

	Modelica does this for its language. Its just a matter of parsing the model and checking which variables we are using the der() and pre() operators on. Right now, the only thing these declarations do is clutter the model or complain when we forget to specify a declaration.		Modelica does this for its language. Its would be just a matter of parsing the model and checking which variables we are using the der() and pre() operators on. Right now, the only thing these declarations do is clutter the model and complain when we forget to specify a declaration.

	2) We could allow conditional expressions inside equations.		2) We could allow conditional expressions inside equations.

	For example, right now we use [[USE]] statements to turn equations on and off ~~like we have right now~~:		For example, right now we use [[USE]] statements to turn equations on and off:

	<nowiki>		<nowiki>
Line 34:		Line 41:
	END EVENT;</nowiki>		END EVENT;</nowiki>

			I would prefer to use boolean expressions instead, similar to how it is possible in Modelica. In ASCEND it would look something like this:
	I would prefer to use boolean expressions instead:

	<nowiki>		<nowiki>
Line 45:		Line 51:
	x = max(y, 0)</nowiki>		x = max(y, 0)</nowiki>

	~~This is another Modelica-inspired feature, BTW.~~ For optimization and [http://book.xogeny.com/behavior/discrete/decay/ advanced tweaking], Modelica also has the `noEvent` and `smooth` operators to "turn off" the automatic event-handling and boundary checking of conditional expressions.		For optimization and [http://book.xogeny.com/behavior/discrete/decay/ advanced tweaking], Modelica also has the `noEvent` and `smooth` operators to "turn off" the automatic event-handling and boundary checking of conditional expressions.

			=== Miscelaneous Modelica features ===
	== Miscelaneous Modelica features ==

	Some Modelica features caught my eye. They wouldn't be a big priority for us, but I think its worth mentioning that they exist.		Some Modelica features caught my eye. They wouldn't be a big priority for us, but I think its worth mentioning that they exist.
Line 57:		Line 62:


	== Hybrid modeling ==		=== Hybrid modeling ===

	For motivation, lets look at the code for a bouncing ball in Modelica:		For motivation, lets look at the code for a bouncing ball in Modelica:
Line 94:		Line 99:
	# Run the evtname_end METHOD to undo the changes from step 4		# Run the evtname_end METHOD to undo the changes from step 4

	Step 1 can get a bit cleaner if we allow boolean expressions instead of ~~jsut~~ boolean variables. I think steps 2 and 3 should be covered by regular conditional equations (what the current WHEN syntax does) and does not have to be the responsibility of the EVENT statement.		Step 1 can get a bit cleaner if we allow boolean expressions instead of just boolean variables. I think steps 2 and 3 should be covered by regular conditional equations (what the current WHEN syntax does) and does not have to be the responsibility of the EVENT statement.

	The really tricky part are steps 4, 5 and 6. This problem of solving the system to find new initial conditions is something that we don't have a good way to express yet in ASCEND. For example, notice how some of the models in the ksenija folder have `before_integ` or `prepare_integ` that should be manually run to find initial conditions. I also needed to do something similar to find steady-state initial conditions in the Lotka-Volterra model I wrote.		The really tricky part are steps 4, 5 and 6. This problem of solving the system to find new initial conditions is something that we don't have a good way to express yet in ASCEND. For example, notice how some of the models in the ksenija folder have `before_integ` or `prepare_integ` that should be manually run to find initial conditions. I also needed to do something similar to find steady-state initial conditions in the Lotka-Volterra model I wrote.

	Right now, I don't know how to fix this problem of specifying initial conditions but I highly suspect that if we can figure this out, the syntax for the hybrid modeling will follow very naturally. ~~What I have now are some questions that if answered I think will get us closer to figuring out a solution:~~		Right now, I don't know how to fix this problem of specifying initial conditions but I highly suspect that if we can figure this out, the syntax for the hybrid modeling will follow very naturally.

	* When we integrate, `t` and the related variables get updated. Are these variables FREE or FIXED? Testing suggests that Ascend wants them to be free before integrating but when solving IVPs we want to fix them (t=0 and so on).
	* Why are we using QRSlv instead of IDA to find the new initial conditions?
	* Is [http://bugs.ascend4.org/view.php?id=472 Bug 472] going to get in our way?

	[[Category:GSOC2016]]		[[Category:GSOC2016]]

Hugo: writeup of language study

2016-06-17T07:15:26Z

writeup of language study

@@ Line 1: / Line 1: @@
-I'm Hugo Gualandi, and am currently pursuing a PhD at [http://www.lua.inf.puc-rio.br/ PUC-Rio university], focusing on programming languages.
+I'm Hugo Gualandi, and am currently pursuing a PhD at [http://www.lua.inf.puc-rio.br/ PUC-Rio university], focusing on programming languages. For [[GSOC2016]], I'm trying to improve ASCEND's conditional modeling syntax.
-For [[GSOC2016]], I'm trying to improve ASCEND's conditional modeling syntax.
+== Goal of the Project ==
 [[Category:GSOC2016]]

Hugo at 18:28, 6 May 2016

2016-05-06T18:28:01Z

← Older revision		Revision as of 18:28, 6 May 2016
Line 1:		Line 1:
			I'm Hugo Gualandi, and am currently pursuing a PhD at [http://www.lua.inf.puc-rio.br/ PUC-Rio university], focusing on programming languages.

			For [[GSOC2016]], I'm trying to improve ASCEND's conditional modeling syntax.

	[[Category:GSOC2016]]		[[Category:GSOC2016]]

Jpye: Created page with "Category:GSOC2016"

2016-05-06T00:49:03Z

Created page with "Category:GSOC2016"

New page

[[Category:GSOC2016]]

← Older revision		Revision as of 05:06, 22 August 2016
Line 1:		Line 1:
	I'm Hugo Gualandi, and am currently pursuing a PhD at [http://www.lua.inf.puc-rio.br/ PUC-Rio university], focusing on programming languages.		I'm Hugo Gualandi, and am currently pursuing a PhD at [http://www.lua.inf.puc-rio.br/ PUC-Rio university], focusing on programming languages. For [[GSOC2016]] I implemented [[OcamlParser\|experimental ASCEND parsers and syntax transformers]].

	== GSOC 2016 Project: Improvements to the Conditional Modeling Syntax ==		== GSOC 2016 Project: Improvements to the Conditional Modeling Syntax ==