New Frontend does not check for circular dependencies in parameter bindings

[Karim Adbdelhak]

Consider following model:

model circularBinding
  parameter Boolean b1 = true;
  parameter Real f = if b1 then g else 2.0;
  parameter Real g = if b1 then 2.0 else f;
end circularBindung;

The old frontend detected the (seemingly) possible circular dependency in the bindings of f and g and marked the condition b1 with final=true. The new frontend does not do that and therefore it fails in the backend.

The minimal thing that is needed is that {b1 has to get final= true, that is what the old frontend does and evaluateParameters in combination with simplifyIfEquations takes care of it. But those models are mostly useless right now and it would be great to get rid of them or at least thin them out (i guess some form of simplification for if equations has to stay).

Optimally the frontend would take care of it, detect and resolve the structural parameters.

Also related:
The old frontend evaluated protected parameters whereas the new frontend does not. As far as i know they can't be changed after compilation anyways, so what is the correct way to handle it?

[Per Östlund]

I would say that that model is not legal according to the specification, since 4.4.3 says that parameters and constants must be acyclic after flattening unless the cycles disappear when evaluating parameters with annotation(Evaluate = true).

The OF doesn't evaluate the if-expressions in either case, while the NF does evaluate both of the if-expressions if b1 is declared with annotation(Evaluate = true). As the model is written I think it should be rejected by the frontend if we want to adhere to the specification. 4.4.3 actually contains an example that is pretty much this exact case, the PartialLumpedVolume case.

Also, the OF doesn't actually mark b1 as structural because it detects a circular dependency, at least not explicitly.

It tries to type the binding of f, which fails because it can't determine the type of g. Then it tries to evaluate b1 instead to select one of the branches, which succeeds so it marks b1 as structural. It still can't determine the type of the selected branch, but it doesn't seem to care about that. It doesn't actually change the binding though, it only evaluates the expression to get its type and then throws the evaluated expression away. So b1 is marked as structural without being evaluated in the flat model.

The NF instead types all the components in one phase, and then their bindings in another phase. It already knows the type of e.g. g when typing the binding of f, so it doesn't have any issues with circular dependencies like this. The OF actually goes into an infinite loop if you change the model to parameter Real g = f;.

[Francesco Casella]

Replying to perost:

I would say that that model is not legal according to the specification, since 4.4.3 says that parameters and constants must be acyclic after flattening unless the cycles disappear when evaluating parameters with annotation(Evaluate = true).

I agree, that's pretty explicit.

The OF doesn't evaluate the if-expressions in either case, while the NF does evaluate both of the if-expressions if b1 is declared with annotation(Evaluate = true). As the model is written I think it should be rejected by the frontend if we want to adhere to the specification. 4.4.3 actually contains an example that is pretty much this exact case, the PartialLumpedVolume case.

Ditto.

[Karim Adbdelhak]

Replying to perost:

As the model is written I think it should be rejected by the frontend if we want to adhere to the specification. 4.4.3 actually contains an example that is pretty much this exact case, the PartialLumpedVolume case.

I agree, this test is actually a stripped down version of a testcase we have in our testsuite. Maybe it should just be removed or annotation(Evaluate = true) should be added.

Any thoughts on the second part about evaluation of protected variables?

[Karim Adbdelhak]

Replying to Karim.Abdelhak:

Any thoughts on the second part about evaluation of protected variables?

While trying to come up with a model that represents the problem, i recognized that it actually is different than i thought. Protected did not get evaluated in the old frontend.

I will try to recreate the problem i had earlier.

[Francesco Casella]

Replying to Karim.Abdelhak:

Any thoughts on the second part about evaluation of protected variables?

I guess you meant parameters :)

See ##5580