[NF] Conditions in IF equations are wrongly marked as structural parameters

[Adrian Pop]

In NFInst we have:
​https://github.com/OpenModelica/OMCompiler/blob/master/Compiler/NFFrontEnd/NFInst.mo#L3054

    case Equation.IF()
      algorithm
        all_params := true;

        for branch in eq.branches loop
          () := match branch
            case Equation.Branch.BRANCH()
              algorithm
                if all_params and Expression.variability(branch.condition) == Variability.PARAMETER then
                  markStructuralParamsExp(branch.condition);
                else
                  all_params := false;
                end if;

                updateImplicitVariabilityEql(branch.body);
              then
                ();
          end match;
        end for;
      then
        ();

If the condition is parameter it doesn't mean they are structural parameters.

The specification says this:

If-equations in equation sections which do not have exclusively 
parameter expressions as switching conditions shall have the 
same number of equations in each branch.

This marking of IF conditions as structural make some models to fail, for example: Modelica.Blocks.Continuous.PID.

In this case we mark as structural:

set structural: I.initType/initType
set structural: initType/initType
set structural: D.initType/initType
set structural: D.zeroGain/zeroGain
set structural: D.k/k
set structural: Td/Td

D.zeroGain is selected as structural parameter because is a parameter and is an IF condition.

D.zeroGain depends on PID.Td which is also marked as structural.
Td in PID has no binding, just a start value and the NFCeval fails.
Now, we could use the start value because Td doesn't have fixed=false but I'm not sure if that is correct.

"[C:/home/adrpo33/dev/OMTesting/nf/pid.mo:176:9-176:92:writable] Notification: From here:
[C:/home/adrpo33/dev/OMTesting/nf/pid.mo:185:40-185:57:writable] Error: Constant Td is used without having been given a value.
[C:/home/adrpo33/dev/OpenModelica/OMCompiler/Compiler/NFFrontEnd/NFCeval.mo:720:9-720:67:writable] Error: Internal error NFCeval.evalBinaryDiv failed to evaluate ‘Td / 1.0‘

How should we fix this? Do we just use the start value?

In general thou', I think we cannot decide on structural parameters for IF equations until we type everything, expand the equations and we check that the number of equations are different in the branches. If the number of equations are different in the branches and the IF conditions depends on parameters that have no bindings, then we can issue an error.

[Per Östlund]

The issue in the NF is that structural parameters needs to be known before the typing, otherwise they won't be replaced everywhere since the replacing is done during the typing. But that's not really possible in all cases, such as here, so I've been slowly getting rid of all such evaluation (like branch selection) during typing and doing it later instead.

I think it's only if-expressions and possibly some unnecessary evaluation of ranges that still needs to be fixed, then we can check structural parameters after the typing and evaluate all constants in a separate phase. The only exception should be dimensions that we do need to evaluate during typing, but any parameter used in a dimension is undoubtedly structural anyway.

[Adrian Pop]

Thanks @perost, that sounds good.
Then I won't force the usage of start attribute for these things as we have a better solution soon.

[Francesco Casella]

Replying to adrpo:

Td in PID has no binding, just a start value and the NFCeval fails.
Now, we could use the start value because Td doesn't have fixed=false but I'm not sure if that is correct.

Section 8.6 of the Modelica Specification

If a parameter has a modifier for the start -attribute, does not have fixed=false, and neither has a binding equation nor is part of a record having a binding equation, the modifier for the start-attribute can be used to add a parameter binding equation assigning the parameter to that start-modifier. In this case a diagnostic message is recommended in a simulation model.

Based on that, I guess it should be correct.

[Adrian Pop]

Use of start attribute implemented in:
​https://github.com/OpenModelica/OMCompiler/pull/2611
Impact:
​https://libraries.openmodelica.org/branches/history/newInst/2018-08-20%2017:36:47..2018-08-20%2020:31:31.html

[Francesco Casella]

I tested the PID model with the NF and with the last commits by @adrpo it works just fine, so I'm closing this ticket.