Better diagnostics for non-balanced models

[Francesco Casella]

OMC currently does not help at all determining why a model is not balanced, and it does not exploit Modelica 3.x rules for doing so.

Consider the following simple example:

model M
  Modelica.Blocks.Sources.RealExpression m1(y = 1);
  Modelica.Blocks.Continuous.FirstOrder m2(k = 1, T = 1);
  Modelica.Blocks.Sources.IntegerExpression m3(y = 1);
  Modelica.Blocks.Math.IntegerToReal m4;
end M;

Trying to simulate it produces the following output:

Error: Too few equations, under-determined system.
The model has 4 equation(s) and 6 variable(s).
Error: pre-optimization module clockPartitioning (simulation) failed.

It's good to know that the simulation failed because of an unbalanced model, but it would be much better to have some hints as to how to fix the problem. In this case, it would be quite easy to see by Modelica 3.x rules (sect. 4.7) that the local number of unknowns of the top-level model is 2, i.e., the sum of the top level public input variables, while the local number of equations is zero, so that the most probable cause of the error is the lack of connect statements involving those input variables. On the other hand, it can be easily determined that the four models m1, m2, m3, and m4 are locally balanced.

Furthermore, running the simulation with -d=execstat reveals that a number of pre-optimization back-end operations are performed on the model:

preOpt normalInlineFunction (simulation),
preOpt evaluateReplaceProtectedFinalEvaluateParameters (simulation)
preOpt simplifyIfEquations (simulation)
preOpt expandDerOperator (simulation)
preOpt removeEqualFunctionCalls (simulation)

IMHO, this a waste of time, as it is already clear from the output of the front-end that the number of equations does not match the number of variables, so that attempting any further optimization is futile. Even worse, any back-end optimization can only have the effect of making the root cause of this problem more obscure to find out, as soon as some diagnostics is in place.

My recommendations:

• Check that the global number of equations and unknowns are matched for each basic type (Real, Integer, and Boolean) right after the front-end phase, and if they are not, do not proceed with the back-end phase and start the diagnostic phase right away
• If the model is globally balanced but later phases of the back-end reveal some singularity, e.g., some parts of the model have too few equations and some others too many, then stop the back-end processing and start the diagnostic phase right away
• For the diagnostic phase, check that the models are locally balanced, starting from the top-level model and proceeding in breadth-first fashion in the analysis of the model instantiation graph

[Francesco Casella]

I think this feature is a must for 2.0.0.

[Francesco Casella]

I guess this should be handled by the new frontend. BTW, if properly applied, these rules can help figure out the balancing of models that contain instances of model defined by partial classes (think of the medium models in the Fluid library), as long as the interfaces of sub-models are clear. This obviously can only be done by the frontend, as you can't fully flatten those models and pass them to the backend because they are incomplete.

@perost, what do you think?