Dependency refinements

[DeadParrot]

Dependencies were added for QSS use based on the need to actively track some algebraic variables that can interact with event triggering outside of a dependency graph path that includes a continuous state variable (e.g. see, DepTest5). The approach was to list all direct dependencies between algebraic, state, and input variable in a <Dependencies> section of the modelDescription.xml file to give QSS the full dependency graph that it could use as needed. Testing and discussions have turned up some problems with this approach:

1. QSS cannot actively track trajectories of variables that have algebraic variable dependencies because it is not legal in current OCT to directly set the value of algebraic variables.
2. There are a very large number of algebraic variables so tracking them all is impractical/inefficient. The subset that must be tracked (those that can change zero-crossing functions without affecting continuous states) could be identified to reduce this burden but that doesn't overcome the first problem.
3. Some of these "signaling" algebraic variables are temporaries that arise from event generating functions (e.g., see DepTest4) and OCT now removes all temporaries from the modelDescription.xml variables and dependencies.

To address these obstacles we believe that a revised approach can work. Essentially, the QSS active simulation dependency graph is reduced to only contain dependencies on continuous states and inputs and event indicators, with the last an addition to cover the effect of event indicator "signaling" via algebraic variables. The details to make this work include:

• For simulation QSS needs the "active" dependency graph that is computed from the "raw" dependency graph by short-circuiting paths through algebraic variables until continuous states, inputs, or event indicators are reached. (Is this the correct definition???)
• OCT could provide QSS with the full "raw" dependency graph and let it do the necessary graph short-circuiting or OCT could do it (which it already does in <ModelStructure> except for event indicator inter-dependencies).
• If this does not capture all mechanisms for signaling a variable that it needs to update then we need to enumerate other scenarios that must be handled.
• In the "raw" dependency graph event indicators depend only variables appearing in their zero-crossing functions, not on other event indicators (that may have related zero-crossing functions).
• In the "raw" dependency graph variables depend on an event indicator (but not the variables contained in its zero-crossing function) if they can be modified within the event "handler" block of the associated if or when conditional.
• In the "raw" dependency graph all the algebraic variables and those that they can cause to change are all in a fully-connected, cyclic dependency sub-graph with each other. The dependencies currently provided by the OCT are not including all of these inter-dependent algebraic variables so QSS cannot properly get the needed dependency graph (see SimpleHouseDiscreteTime and the rad.port_b.h_outflow and rad.vol[5].dynBal.medium.T variables).

Dependencies for QSS

Dependencies in QSS have two related purposes that the exposed dependencies must represent:

1. Signaling observers to update when a variable changes.
2. Setting observees' values in the FMU to retrieve a variable's value from the FMU.

Outputs

• Output and local variables may be of interest for results outputs.
• In <Outputs> the state and input dependencies are provided for output variables that should allow their value to be retrieved from the FMU by setting the values of the dependencies in the FMU (confirm this).
• With similar dependency information for local variables QSS could do more efficient output generation and have simpler output code. Are the downsides (larger modelDescription.xml, slowing input processing, slower FMU if the locals are treated as outputs(?), ...) greater than the benefit?

Implementation Proposal

1. Continue using <Dependencies> section for QSS for now so that we can adjust/add dependencies beyond what is in <ModelStructure>. If we find there is no difference we can eventually drop <Dependencies>.
2. Dependencies between event indicators that represent change signaling must be provided and distinguished from those that appear because the event indicator zero-crossing functions share a common expression. QSS doesn't need to know about the latter "dependency" so simply eliminating those from the <Dependencies> section would work.

Open Questions

1. Are there any problems with this approach such as Modelica/OCT restrictions?
2. Should OCT <Dependencies> provide the "raw" or short-circuited dependency graphs?
3. How/when are algebraic variables updated in the FMU when states and inputs change and event indicators fire?

[DeadParrot]

Here are some specific examples of OCT Dependencies that will need changing to work with this proposed design.

Variables modified within an event indicator's "handler" block are missing dependencies from those equations. So with this usage v will not show a dependency on time:

  when h < 0 then
    reinit(v, time);
  end when;

Edit: Fixed as of OCT-master-8bb4688ea939e98a3f23be67236795ab5f2d3ac4.

And with this usage discrete variable d will not show a self-dependency:

  when time >= pre(d) + 1 then
    d = pre(d) + 1;
  end when;

OCT short-circuits intermediate (not continuous state) variables out of the dependencies but QSS can exploit the option of keeping them as active update signaling variables.

For this model OCT gives a dependency of the time < 1 event indicator on t instead of time:

model X
  output Real t;
  output Real r(start = 0, fixed = true);
equation
  t = time + 1;
  if time < 1 then
    r = time * time;
  else
    r = t;
  end if;
annotation( experiment(StartTime=0, StopTime=5, Tolerance=1e-4) );
end X;

While time and t are closely related this is not the natural dependency that QSS will expect.

For this model OCT gives a dependency of the time >= 1 event indicator on the time < 1 event indicator instead of time:

model X
  output Real r1(start = 0, fixed = true);
  output Real r2(start = 1, fixed = true);
equation
  when time < 1 then
    r1 = sin(time);
    r2 = cos(time);
  elsewhen time >= 1 then
    r1 = pre(r2) + time;
    r2 = pre(r1) + time;
  end when;
annotation( experiment(StartTime=0, StopTime=5, Tolerance=1e-4) );
end X;

QSS needs the actual direct dependencies in this case because dependencies between event indicators are used when an intermediate signaling variable modified in conditional "handler" block that also appears in the zero-crossing function of an event indicator is short-circuited out of the dependencies. The meaning of the dependency here is different, that OCT finds the event indicators to share the same form or dependencies, which QSS cannot distinguish from the other meaning. Note: A temporary work-around was added to QSS to allow for both meanings when EI->EI dependencies are present, which should allow correct simulation at some efficiency cost.

The Dependencies behavior described is based on the OCT update version OCT-master-7245bce03ab2ebdfdaaf0805d75209efaa009c67.