ASCEND - User contributions [en]

OcamlParser

2016-08-22T16:49:39Z

Hugo:

For [[GSOC2016]], [[User:Hugo|Hugo]] implemented an experimental parser for the ASCEND modeling language that allows a faster rate of experimentation for new syntactic features compared to the existing ASCEND parser.

The new parser was designed to make it easy to parse ASCEND syntax into a syntax tree, perform transformation passes over this syntax tree and then serialize the result back into a textual format, which can be fed into the existing ASCEND compiler. This lets us implement new language features in terms of existing ones and experiment without needing to modify the core ASCEND compiler.

One advantage of having this new parser and syntax-tree tooling is that working with syntax trees is hard to do in the existing parsing architecture because ASCEND's C compiler parses and interprets the code at the same time, and doesn't give us a chance to apply syntax transformers before the code is interpreted. Another advantage of the new parser is that it is written in [https://ocaml.org/ Ocaml], which as a functional programming language is specially suited for operating on tree-like data structures.

== Compiling and Using the New Parser ==

The code for the new experimental parser as well as the infrastructure for writing syntax transformers can currently be found in the {{srcbranchdir|hugo|}} branch of the ASCEND Subversion repository. It has not been merged into the trunk yet.

<nowiki>
svn co http://svn.ascend4.org/branches/hugo ascend-hugo</nowiki>

To run the new parser and to write syntax transformers, you will need to install the Ocaml compiler, and some Ocaml libraries. The recommended way to do this is to use your distro's package manager to install the Ocaml compiler and the [https://opam.ocaml.org/ Opam] package manager and then use Opam to download and install the required Ocaml libraries.

<source lang=sh>
sudo apt-get install ocaml opam

opam init
opam install menhir containers sequence
</source>

Then, go to the "ocaml" folder in the ASCEND source directory and build things with the makefile. Now you can start playing with the new parser.

<source lang=sh>
cd ascend-hugo/ocaml
make
</source>

The makefile, {{srcbranch|hugo|ocaml/makefile}}, shows how to compile the code and the tests filder has some examples of how to run it. For more details see {{srcbranch|hugo|ocaml/README.txt}}.

== Writing Syntax Transformers ==

The goal of this new Ocaml parser is to support syntax experiments that work by mapping ASCEND syntax trees (possibly with some extensions) into a vanilla ASCEND syntax tree that can be fed into the existing C compiler. However, writing these syntax tree transformers by hand can be a very laborious process because you need to write a lot of code just to traverse the syntax tree and get to the interesting leaves that we might want to modify. (Have a look at {{srcbranch|hugo|ocaml/tokenize_tree.ml}} to see how traversing a tree by hand looks like).

One of the ways to avoid boilerplate traversal code is to use the "Visitor Pattern" and write traversals by extending a default traversal that doesn't do anything. To support this pattern, there is an interface for syntax tree iterators in {{srcbranch|hugo|ocaml/ast_iterator.ml}} as well as a default_iterator that doesn't do anything but that can be easily extended into an iterator that does something interesting in relevant nodes and just walks through everything else. There is also a similar system for transformers (functions that convert one AST into another) in {{srcbranch|hugo|ocaml/ast_mapper.ml}}.

A good example of how to use the tree iteration and transformation modules can be found in {{srcbranch|hugo|ocaml/infer_derivatives.ml}}. This syntax transformer receives makes <code>DERIVATIVE OF</code> declarations optional by inferring them from the uses of the <code>der()</code> operator throughout the program.

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

OcamlParser

2016-08-22T08:23:53Z

Hugo:

For [[GSOC2016]], [[User:Hugo|Hugo]] implemented an experimental parser for the ASCEND modeling language that allows a faster rate of experimentation for new syntactic features compared to the existing ASCEND parser.

The new parser was designed to make it easy to parse ASCEND syntax into a syntax tree, perform transformation passes over this syntax tree and then serialize the result back into a textual format, which can be fed into the existing ASCEND compiler. This lets us implement new language features in terms of existing ones and experiment without needing to modify the core ASCEND compiler.

One advantage of having this new parser and syntax-tree tooling is that working with syntax trees is hard to do in the existing parsing architecture because ASCEND's C compiler parses and interprets the code at the same time, and doesn't give us a chance to apply syntax transformers before the code is interpreted. Another advantage of the new parser is that it is written in Ocaml, which as a functional programming language is specially suited for operating on tree-like data structures.

== Compiling and Using the New Parser ==

The code for the new experimental parser as well as the infrastructure for writing syntax transformers can currently be found in the {{srcbranchdir|hugo|}} branch of the ASCEND Subversion repository. It has not been merged into the trunk yet.

<nowiki>
svn co http://svn.ascend4.org/branches/hugo ascend-hugo</nowiki>

To run the new parser and to write syntax transformers, you will need to install the Ocaml compiler, and some Ocaml libraries. The recommended way to do this is to use your distro's package manager to install the Ocaml compiler and the [https://opam.ocaml.org/ Opam] package manager and then use Opam to download and install the required Ocaml libraries.

<source lang=sh>
sudo apt-get install ocaml opam

opam init
opam install menhir containers sequence
</source>

Then, go to the "ocaml" folder in the ASCEND source directory and build things with the makefile. Now you can start playing with the new parser.

<source lang=sh>
cd ascend-hugo/ocaml
make
</source>

The makefile shows how to compile the code and the tests filder has some examples of how to run it. For more details see {{srcbranch|hugo|ocaml/README.txt}}.

== Writing Syntax Transformers ==

The goal of this new Ocaml parser is to support syntax experiments that work by mapping ASCEND syntax trees (possibly with some extensions) into a vanilla ASCEND syntax tree that can be fed into the existing C compiler. However, writing these syntax tree transformers by hand can be a very laborious process because you need to write a lot of code just to traverse the syntax tree and get to the interesting leaves that we might want to modify. (Have a look at tokenize_tree to see how traversing a tree by hand looks like).

One of the ways to avoid boilerplate traversal code is to use the "Visitor Pattern" and write traversals by extending a default traversal that doesn't do anything. To support this pattern, there is an interface for syntax tree iterators in ast_iterator.ml as well as a default_iterator that doesn't do anything but that can be easily extended into an iterator that does something interesting in relevant nodes and just walks through everything else. There is also a similar system for transformers (functions that convert one AST into another) in ast_mapper.ml.

A good example of how to use the tree iteration and transformation modules can be found in infer_derivatives.ml. This syntax transformer receives makes <code>DERIVATIVE OF</code> declarations optional by inferring them from the uses of the <code>der()</code> operator throughout the program.

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

User:Hugo

2016-08-22T05:06:49Z

Hugo: More prominent link

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 ==

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
* Right now some models break badly without redundant information ([[FIX]] and [[FREE]] in hybrid models)
* Sometimes, we have redundant information that could have been inferred by a smarter compiler

2) Make modeling less error prone
* Right now, hybrid modeling relies on calling methods that run [[FIX]], [[FREE]] and set variables by hand. This is very error prone and violates some of the ASCEND abstractions.
* 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 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 ===

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

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.

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

<nowiki>
on: P = 3000;
off: P = 0;

ev1: EVENT (too_high)
CASE TRUE: USE off;
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:

<nowiki>
P = if on then 3000 else 0;</nowiki>

Another good application of conditional expressions would be piecewise functions such as min(), max() and abs(). They resulting code can end up more concise than conditional equations.

<nowiki>
x = max(y, 0)</nowiki>

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 ===

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

1) You can use a buit-in function to create an event that runs every X seconds. In Ascend I think you would need to abuse a periodic function such as sin() to achieve this effect.

2) The terminate() builtin lets you cleanly halt the integration from inside an event handler.

=== Hybrid modeling ===

For motivation, lets look at the code for a bouncing ball in Modelica:

<nowiki>
model BouncingBall "The 'classic' bouncing ball model"
type Height=Real(unit="m");
type Velocity=Real(unit="m/s");
parameter Real e=0.8 "Coefficient of restitution";
parameter Height h0=1.0 "Initial height";
Height h;
Velocity v;
initial equation
h = h0;
equation
der(h) = v
der(v) = -9.81;
when h<0 then
reinit(v, -e*pre(v));
end when;
end BouncingBall;</nowiki>

Some interesting things that I think of this:
* The Hybrid modeling happens via a `reinit` statement that "sets" a variable to a new value. We were asking if maybe something more general would be needed but Modelica suggests that these "assignments" are enough.
* However, `reinit` is not a plain assignment. It also recomputes the initial conditions appropriately.
* There are special equations for specifying the initial conditions. In more advanced cases, these equations can be things like `der(x) = 0`.

Now, lets compare this to how ASCEND handles [[EVENT]] statements

# Detect when a boolean variable flips from FALSE to TRUE
# Deactivate equations from OTHERWISE clause.
# Activate equations in the CASE TRUE clause.
# Run the evtname METHOD to fix/free variables.
# Run QRSlv
# 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 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.

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.

[[Category:GSOC2016]]

User:Hugo

2016-08-22T05:03:58Z

Hugo: update page for the GSOC final evaluation

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.

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

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
* Right now some models break badly without redundant information ([[FIX]] and [[FREE]] in hybrid models)
* Sometimes, we have redundant information that could have been inferred by a smarter compiler

2) Make modeling less error prone
* Right now, hybrid modeling relies on calling methods that run [[FIX]], [[FREE]] and set variables by hand. This is very error prone and violates some of the ASCEND abstractions.
* 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 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 ===

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

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.

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

<nowiki>
on: P = 3000;
off: P = 0;

ev1: EVENT (too_high)
CASE TRUE: USE off;
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:

<nowiki>
P = if on then 3000 else 0;</nowiki>

Another good application of conditional expressions would be piecewise functions such as min(), max() and abs(). They resulting code can end up more concise than conditional equations.

<nowiki>
x = max(y, 0)</nowiki>

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 ===

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

1) You can use a buit-in function to create an event that runs every X seconds. In Ascend I think you would need to abuse a periodic function such as sin() to achieve this effect.

2) The terminate() builtin lets you cleanly halt the integration from inside an event handler.

=== Hybrid modeling ===

For motivation, lets look at the code for a bouncing ball in Modelica:

<nowiki>
model BouncingBall "The 'classic' bouncing ball model"
type Height=Real(unit="m");
type Velocity=Real(unit="m/s");
parameter Real e=0.8 "Coefficient of restitution";
parameter Height h0=1.0 "Initial height";
Height h;
Velocity v;
initial equation
h = h0;
equation
der(h) = v
der(v) = -9.81;
when h<0 then
reinit(v, -e*pre(v));
end when;
end BouncingBall;</nowiki>

Some interesting things that I think of this:
* The Hybrid modeling happens via a `reinit` statement that "sets" a variable to a new value. We were asking if maybe something more general would be needed but Modelica suggests that these "assignments" are enough.
* However, `reinit` is not a plain assignment. It also recomputes the initial conditions appropriately.
* There are special equations for specifying the initial conditions. In more advanced cases, these equations can be things like `der(x) = 0`.

Now, lets compare this to how ASCEND handles [[EVENT]] statements

# Detect when a boolean variable flips from FALSE to TRUE
# Deactivate equations from OTHERWISE clause.
# Activate equations in the CASE TRUE clause.
# Run the evtname METHOD to fix/free variables.
# Run QRSlv
# 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 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.

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.

[[Category:GSOC2016]]

OcamlParser

2016-08-22T04:50:39Z

Hugo: Created page with "For GSOC2016, Hugo implemented an experimental parser for the ASCEND modeling language that allows a faster rate of experimentation for new syntactic feature..."

For [[GSOC2016]], [[User:Hugo|Hugo]] implemented an experimental parser for the ASCEND modeling language that allows a faster rate of experimentation for new syntactic features compared to the existing ASCEND parser.

The new parser was designed to make it easy to parse ASCEND syntax into a syntax tree, perform transformation passes over this syntax tree and then serialize the result back into a textual format, which can be fed into the existing ASCEND compiler. This lets us implement new language features in terms of existing ones and experiment without needing to modify the core ASCEND compiler.

One advantage of having this new parser and syntax-tree tooling is that working with syntax trees is hard to do in the existing parsing architecture because ASCEND's C compiler parses and interprets the code at the same time, and doesn't give us a chance to apply syntax transformers before the code is interpreted. Another advantage of the new parser is that it is written in Ocaml, which as a functional programming language is specially suited for operating on tree-like data structures.

== Compiling and Using the New Parser ==

The code for the new experimental parser as well as the infrastructure for writing syntax transformers can currently be found in the "hugo" branch of the ASCEND Subversion repository. It has not been merged into the trunk yet.

<nowiki>
svn checkout http://svn.ascend4.org/branches/hugo ascend-hugo</nowiki>

To run the new parser and to write syntax transformers, you will need to install the Ocaml compiler, the [https://opam.ocaml.org/ Opam] package manager and some additional dependencies.

<nowiki>
# Install Ocaml and the Opam package manager
sudo apt-install ocaml opam

# Install Ocaml dependencies (locally)
opam install menhir containers sequence</nowiki>

Then, go to the "ocaml" folder in the ASCEND source directory and build things with the makefile. Now you can start playing with the new parser.

<nowiki>
cd ascend-hugo
cd ocaml
make</nowiki>

The makefile shows how to compile the code and the tests filder has some examples of how to run it. For more details see the README.txt in the ocaml folder.

== Writing Syntax Transformers ==

The goal of this new Ocaml parser is to support syntax experiments that work by mapping ASCEND syntax trees (possibly with some extensions) into a vanilla ASCEND syntax tree that can be fed into the existing C compiler. However, writing these syntax tree transformers by hand can be a very laborious process because you need to write a lot of code just to traverse the syntax tree and get to the interesting leaves that we might want to modify. (Have a look at tokenize_tree to see how traversing a tree by hand looks like).

One of the ways to avoid boilerplate traversal code is to use the "Visitor Pattern" and write traversals by extending a default traversal that doesn't do anything. To support this pattern, there is an interface for syntax tree iterators in ast_iterator.ml as well as a default_iterator that doesn't do anything but that can be easily extended into an iterator that does something interesting in relevant nodes and just walks through everything else. There is also a similar system for transformers (functions that convert one AST into another) in ast_mapper.ml.

A good example of how to use the tree iteration and transformation modules can be found in infer_derivatives.ml. This syntax transformer receives makes <code>DERIVATIVE OF</code> declarations optional by inferring them from the uses of the <code>der()</code> operator throughout the program.

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

User:Hugo

2016-06-17T07:15:26Z

Hugo: writeup of language study

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.

== Goal of the Project ==

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

1) Reducing redundancy in the specification
* Right now some models break badly without redundant information ([[FIX]] and [[FREE]] in hybrid models)
* Sometimes, we have redundant information that could have been inferred by a smarter compiler

2) Make modeling less error prone
* Right now, hybrid modeling relies on calling methods that run [[FIX]], [[FREE]] and set variables by hand. This is very error prone and violates some of the ASCEND abstractions.
* 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...

== Easy redundancy reduction ==

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.

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:

<nowiki>
on: P = 3000;
off: P = 0;

ev1: EVENT (too_high)
CASE TRUE: USE off;
END EVENT;</nowiki>

I would prefer to use boolean expressions instead:

<nowiki>
P = if on then 3000 else 0;</nowiki>

Another good application of conditional expressions would be piecewise functions such as min(), max() and abs(). They resulting code can end up more concise than conditional equations.

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

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

1) You can use a buit-in function to create an event that runs every X seconds. In Ascend I think you would need to abuse a periodic function such as sin() to achieve this effect.

2) The terminate() builtin lets you cleanly halt the integration from inside an event handler.

== Hybrid modeling ==

For motivation, lets look at the code for a bouncing ball in Modelica:

<nowiki>
model BouncingBall "The 'classic' bouncing ball model"
type Height=Real(unit="m");
type Velocity=Real(unit="m/s");
parameter Real e=0.8 "Coefficient of restitution";
parameter Height h0=1.0 "Initial height";
Height h;
Velocity v;
initial equation
h = h0;
equation
der(h) = v
der(v) = -9.81;
when h<0 then
reinit(v, -e*pre(v));
end when;
end BouncingBall;</nowiki>

Some interesting things that I think of this:
* The Hybrid modeling happens via a `reinit` statement that "sets" a variable to a new value. We were asking if maybe something more general would be needed but Modelica suggests that these "assignments" are enough.
* However, `reinit` is not a plain assignment. It also recomputes the initial conditions appropriately.
* There are special equations for specifying the initial conditions. In more advanced cases, these equations can be things like `der(x) = 0`.

Now, lets compare this to how ASCEND handles [[EVENT]] statements

# Detect when a boolean variable flips from FALSE to TRUE
# Deactivate equations from OTHERWISE clause.
# Activate equations in the CASE TRUE clause.
# Run the evtname METHOD to fix/free variables.
# Run QRSlv
# 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.

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:

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

Thin-walled tank/Adding methods to a model

2016-05-25T20:50:58Z

Hugo: /* Adding methods to the thin-walled tank model */

{{thinwalled}}
In this part, we continue the example we introduced in Part 1. Our goal is to provide an introductory tutorial into using the ASCEND modeling environment. We shall show how to add METHODS to models to make them more useful for sharing with others and/or with oneself at a later time.

== Introduction: making a model sharable==

We shall say a model is sharable if one can use and understand it without being its developer. Being able to solve a model at least one time without first understanding it can aid significantly in learning about the model, especially in a modeling environment such as ASCEND that allows one to explore a solved model instance in detail.

In Part 1, our ASCEND model was a nonprocedural listing of the variables and equations that must be true at the model solution. There were no statements as to how to solve the model. We know that solving large nonlinear models can be very difficult numerically and can require the modeler to provide a lot of special knowledge to coerce the model to a solution. We want to add this knowledge to the code defining the model without forcing a modeler to use that knowledge when using the same model in a different manner - such as to solve for a different set of fixed variables or when embedding the model as a part of a larger model.

Our approach in ASCEND is to allow modelers to add any number of methods to a model. Methods are executable procedures that can alter the values of the variables and flags within a model instance and that can trigger the execution of other methods. One writes them within within a [[METHODS]] section for the model.

== Adding methods to the '''thin-walled''' tank model ==

The following is our '''thin walled''' tank example with an added [[METHODS]] section.

<source lang="a4c">(* this is file twt0210.a4c *)
REQUIRE "atoms.a4l";

MODEL thin_walled_tank;

(* fixed variables *)
D,
H,
wall_thickness IS_A distance;

metal_density IS_A mass_density;

(* computed variables *)
end_area,
side_area IS_A area;

wall_vol IS_A volume;
metal_mass IS_A mass;

(* equations *)

end_area=3.1416*D^2/4;
side_area=3.1416*D*H;

wall_vol=(side_area+2*end_area)*wall_thickness;
metal_mass=metal_density*wall_vol;

METHODS

METHOD specify;
FIX D;
FIX H;

FIX wall_thickness;
FIX metal_density;
END specify;

METHOD values;
D := 20.0 {cm};
H := D/10.0;

wall_thickness := 0.15 {cm};
metal_density := 7.85 {g/cm^3};

END values;

METHOD setup;
RUN specify;

RUN values;
END setup;

END thin_walled_tank;</source>

We include three methods: specify - to set the fixed flags for the fixed variables, values - to provide values for these four fixed variables and setup - to trigger the running of the other two methods. A user of this model within the TclTK interface would load it, compile it, and export it to the solver. With a tool within the solver, he would trigger the method "setup" to run. Finally he would solve the well-posed model. Note that he could do all these steps without understanding anything about the model. When done, he would have a solved model instance that he could then examine in detail using many of the available tools.

A method is a procedure. Thus statements that set values for the variables are of the general form

<source lang="a4c">LHS variable := RHS expression;</source>

This statement states that ASCEND is to replace the value of the LHS variable with the current value of the RHS expression. The replacement equals (:=) is not the equation equals (=) that we used in the nonprocedural part of our model.

==Discussion==

Note that the METHODS section provides procedures a model user can invoke only when he wishes. Running "setup" blindly sets up his model for solving. As the original modeler will have tested this model before making it available, he would know that running "setup" creates a model instance that will solve. He has thus passed this information along to the subsequent user, making the model more sharable than before.

Also note that the second user of this model does not need to use any of these methods. It is still a model he could play with interactively in many other ways. It has just provided him with one way to get a first solution to examine.

==Standardized set of methods==

We advise modelers using ASCEND to develop a number of different methods for a model. That these methods exist and are useful is supported by our experiences with using ASCEND. Note that no method has to be there. We give several of these methods standard names, and both the TclTk and PyGTK interfaces discover and trigger some of these methods automatically when compiling and solving a model. A significant difference between the two interfaces is the number of methods each expects and triggers automatically, with the PyGTK using methods as a means to make one's first experience with a model appear to be very simple. We describe here the methods these interfaces anticipate being in a model.

See also [[METHODS]].

Continue with [[Thin-walled_tank/Building_complex_models|the next section, Building complex models]]

[[Category:Examples]]
[[Category:Tutorials]]

User:Hugo

2016-05-06T18:28:01Z

Hugo: