MCP-0012: Calling blocks as functions

[modelica-trac-importer]

Reported by otter on 12 Jun 2014 04:18 UTC
A new Modelica Change Proposal Idea (MCPI 0012) has been submitted on svn to call blocks as functions in a restricted form. The MCPI is found here

  https://svn.modelica.org/projects/MCP-Ideas/MAinternal/MCPI-0012_CallingBlocksAsFunctions/MCPI-0012_CallingBlocksAsFunctions.pdf

This ticket shall support the corresponding discussion for the MCPI and enable everyone to give feedback

---

Migrated-From: https://trac.modelica.org/Modelica/ticket/1512

[modelica-trac-importer]

Comment by msasena on 12 Jun 2014 19:09 UTC
I'd like to better understand what restrictions are limiting the proposal to only applying this concept to the declaration section. There could be some real advantages to allowing it in the equation section as well. Let's explore what might happen if the concept were applied in an equation section and extended to allowing any multiple outputs. Consider this example:

block B1
  input Real u1, u2;
  output Real y1;
  Real x(start=0);
equation
  der(x) = x + u1 + u2;
  when u1 > 0 then
    reinit(x, 0);
  end when;
  y1 = 2 * x;
end B1;

block B2
  input Real u1, u2;
  output Real y1, y2;
  Real x(start=0);
equation
  der(x) = x + u1 + u2;
  y1 = x - u1;
  y2 = x + u2;
end B2;

model M
  Real x1(start=0), x2(start=0), x3(start=0);
  protected Real der_x1, der_x2;
equation
  (der_x1, der_x2) = B2(x1, x2); // anonymous instantiation of B2
  der(x1) = der_x1;
  der(x2) = der_x2;
  0 = x3 + B1(x1, x2); // anonymous instantiation of B1
end M;

This would be conceptually expanded to the following:

model instance m
  Real x1(start=0), x2(start=0), x3(start=0);
  B1 b1;
  B2 b2;
  protected Real der_x1, der_x2;
equation
  b2.u1 = x1;
  b2.u2 = x2;
  der_x1 = b2.y1;
  der_x2 = b2.y2;
  der(x1) = der_x1;
  der(x2) = der_x2;
  b1.u1 = x1;
  b1.u2 = x2;
  0 = x3 + b1.y1;
end m;

then to:

model instance m
  Real x1(start=0), x2(start=0), x3(start=0);
  Real b1.u1, b1.u2;
  Real b1.y1;
  Real b1.x(start=0);
  Real b2.u1, b2.u2;
  Real b2.y1, b2.y2;
  Real b2.x(start=0);
equation
  b2.u1 = x1;
  b2.u2 = x2;
  der_x1 = b2.y1;
  der_x2 = b2.y2;
  der(x1) = der_x1;
  der(x2) = der_x2;
  b1.u1 = x1;
  b1.u2 = x2;
  0 = x3 + b1.y1;
  der(b2.x) = b2.x + b2.u1 + b2.u2;
  b2.y1 = b2.x - b2.u1;
  b2.y2 = b2.x + b2.u2;
  der(b1.x) = b1.x + b1.u1 + b1.u2;
  when b1.u1 > 0 then
    reinit(b1.x, 0);
  end when;
  b1.y1 = 2 * b1.x;
end m;

And of course you can do this with any kind of type-compatible block. If the execution semantics is given by an algorithm, then simply add the corresponding algorithm to the final expanded class instance. Where does the difficulty lie in allowing calling blocks with functional syntax as shown above? What we gain with this feature is that:

1. functions mostly become redundant in Modelica since a block can include algorithms just like functions (handling external code may be a separate issue), and
2. we potentially have a clean way to deal with events, since blocks handle them properly (as regular Modelica models, contrary to functions)

The second point is the important one. Blocks already have a clearly defined way of handling events. Moreover they support both algorithm and equation sections. There have been a lot of discussions about event handling in functions and the problems posed because functions only allow algorithms. By allowing blocks to be used with a similar syntax to function calls, we've provided a clean way to handle events with "function-like" calls using the existing Modelica semantics. It's purely a syntatic addition and therefore relatively straightforward for tool vendors to implement. Also, as suggested in Design Meeting 82, this may address some of the problems with fluid properties models.

[modelica-trac-importer]

Comment by choeger on 12 Jun 2014 19:47 UTC
Replying to [comment:1 msasena]:

1. functions mostly become redundant in Modelica since a block can include algorithms just like functions (handling external code may be a separate issue), and

While I support the idea of generalization, I have to disagree with you on that point. As you mention in your second point, there is a distinct difference between a block-instance and a function application (namely that the former one has a clear influence on what the solver "sees" of the model, e.g. regarding event handling).

So I'd like to add the following proposal: Make block-application possible but syntactically distinguishable from function applications. IMO it is better in general, to make different things look differently. Overloading the syntax too much produces confusion and errors.