User:Hugo

I'm Hugo Gualandi, and am currently pursuing a PhD at 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:

on: P = 3000;
off: P = 0;
 
ev1: EVENT (too_high)
    CASE TRUE: USE off;
END EVENT;

I would prefer to use boolean expressions instead:

P = if on then 3000 else 0;

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.

x = max(y, 0)

This is another Modelica-inspired feature, BTW. For optimization and 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:

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;

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

1. Detect when a boolean variable flips from FALSE to TRUE
2. Deactivate equations from OTHERWISE clause.
3. Activate equations in the CASE TRUE clause.
4. Run the evtname METHOD to fix/free variables.
5. Run QRSlv
6. 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 Bug 472 going to get in our way?