Improve selection of start attributes for alias variables

[Francesco Casella]

The selection of start attributes in alias variable sets is a crucial issue: oftentimes one element of the alias variable set has a carefully user-selected value, while the other ones have default values. It is of paramount importance that the user-selected value is used by the back-end, e.g. to set up the initial guess of iterative solvers, and that this value is not overridden by other less relevant defaults.

This issue has been well-known in the Modelica community for a long time, and actually brought to ​Section 8.6.2 of the Modelica specification. However, it seems to me that the criterion put forward there doesn't cover all the cases satisfactorily. This leads to the detection of start value conflicts which aren't really there, or (worse) to the selection of the wrong start values, which is what I am constantly experiencing with steam power plant models.

Consider the following examples

package Aliases
  type Temperature = Real(start = 300, unit="K");
  type Power = Real(unit="W");

  connector Port
    Temperature T;
    flow Power Q;
  end Port;

  model TemperatureSource
    parameter Temperature Tstart = 320;
    Temperature T1;
    Temperature T2(start = 310);
    Temperature T3(start = Tstart);
    Port port;
  equation
    port.T = T1;
    T1 = T2;
    T2 = T3;
    T1+1e-6*sin(T1) = 300 "Implicit equation on T1";
  end TemperatureSource;
  
  model PowerSource
    parameter Temperature Tstart = 320;
    Port port;
    Temperature T1;
    Temperature T2(start = 330);
    Temperature T3(start = Tstart);
  equation
    port.T = T1;
    T1 = T2;
    T2 = T3;
    port.Q - (port.T-300) = sin(time);
  end PowerSource;

  model WrappedTemperatureSource
    parameter Temperature Tstart = 345;
    Port port;
    TemperatureSource ts(Tstart = Tstart);
  equation
    connect(ts.port, port);
  end WrappedTemperatureSource;  
  
  model WrappedPowerSource
    parameter Temperature Tstart = 345;
    Port port;
    PowerSource ps(Tstart = Tstart);
  equation
    connect(ps.port, port);
  end WrappedPowerSource;  
  
  model System1
    TemperatureSource ts;
    PowerSource ps;
  equation
    connect(ts.port,ps.port);
  end System1;
  
  model System2
    TemperatureSource ts(Tstart = 350);
    PowerSource ps;
  equation
    connect(ts.port,ps.port);
  end System2;
  
  model System3
    TemperatureSource ts(T1(start = 360));
    PowerSource ps;
  equation
    connect(ts.port,ps.port);
  end System3;
  
  model System4
    WrappedTemperatureSource ts(Tstart = 370);
    PowerSource ps;
  equation
    connect(ts.port,ps.port);
  end System4;
  
  model System5
    TemperatureSource ts;
    WrappedPowerSource ps(Tstart = 380);
  equation
    connect(ts.port, ps.port);
  end System5;

  model System6
    WrappedTemperatureSource ts(ts(T1(start = 390)));
    WrappedPowerSource ps(Tstart = 400);
  equation
    connect(ts.port, ps.port);
  end System6;
end Aliases;

At the end of the day, after alias elimination, each of these models has two unknowns: a power flow and a temperature. Everything else are aliases.

As an end-user and library developer, I would like the following start values to be selected for the temperature:

• System1: 320
• System2: 350
• System3: 360
• System4: 370
• System5: 380
• System6: 390

As far as I understand, the current rules of Section 8.6.2 do not guarantee these choices are taken. In fact, with the current 1.16.0-dev version of OMC, I get:

• System1: 330
• System2: 330
• System3: 330
• System4: 330
• System5: 300
• System6: 330

which is never the value I would expect. I haven't checked with Dymola yet, but I suspect the results will be similar.

We should

1. figure out rules to guarantee those choices are made
2. understand how to collect the relevant information in the frontend and pass it to the backend
3. promote a discussion with the MAP-LIB and MAP-LANG projects to standardize the solution

Regarding point 1, I have some loosely formulated requirements, but they need to be formalized into actual rules for the compiler

• type defaults have the lowest priority, they should only be used if there are no other start value specification overriding them
• start values set by modifications when instantiating components should have higher priority than start values set by default binding equations in component declarations
• the priority of start values given by parameters should be determined on the basis of where the actual parameter value is specified
• direct specifications of the start value from the top level of the model to be simulated via nested modifiers should have the precedence over the other start values specified insied the lower-level components
• even in case the parameters are evaluated, the priority information should be computed by the frontend (particularly when evaluating parameters!) and then passed along to the backend, in order to be able to make the correct choices when performing alias elimination

Any ideas/comments?