Protected top-level input connectors are not handled correctly by the NF

[Francesco Casella]

Please run the following test case

model TestProtectedInput
  protected
    Modelica.Blocks.Interfaces.BooleanInput u;
equation
  u = time > 1 and time < 2;
  annotation(
    experiment(StopTime = 10));
end TestProtectedInput;

OMEdit outputs two red error messages:

[1] 12:51:14 Symbolic Error
Too many equations, over-determined system. The model has 1 equation(s) and 0 variable(s).

[2] 12:51:14 Translation Error
[TestProtectedRealInput: 5:3-5:47]: Internal error u = if time > 1.0 and time < 2.0 then 1.0 else 0.0 has size size 1 but 0 variables ()

The protected input u is just one variable as any other one, why isn't it counted as such?

Then, the model runs anyway and produces a wrong result, but that's another story, probably related to #5564.

[Per Östlund]

This isn't a frontend issue, it's the backend that counts variables/equations.

[Karim Adbdelhak]

How should this be detected? It is a protected input which is only unknown when not connected to a public input. Do you tag this input somehow in the frontend? I see it as quite a mess to look for missing connections in the backend.

Well but if per is sure about this i will have a look at it.

[Francesco Casella]

Replying to Karim.Abdelhak:

How should this be detected? It is a protected input which is only unknown when not connected to a public input. Do you tag this input somehow in the frontend? I see it as quite a mess to look for missing connections in the backend.

@Karim, there is no need at all to look for missing connection. All the variables in protected top-level connectors are unknowns of the problem, whether or not the connector is actually part of a connection statement. It is up to the modeller to set up the proper connect statements and additional equations to make sure the model is balanced.

The problem here is is that for some reason they are not considered as such when doing the variable/equation counting.

If a top-level public connector is unconnected, then its variables are also unknown and default equations are generated for it: e.g., top level public inputs are set to zero, if the system is simulated by itself, or they could get their values from the outside in the case of generation of an FMI block. So, in that case you need to look for missing connections. That is already done, and works fine. But that's not the case here.

Replying to perost:

This isn't a frontend issue, it's the backend that counts variables/equations.

If I look at the output of the compilation of any model, with -d=execstat turned on, I get something like this:

Running command: translateModel(Modelica.Blocks.Examples.Filter,tolerance=1e-06,outputFormat="mat",numberOfIntervals=5000,variableFilter="time|Bessel.x.1.|Bessel.x.2.|Bessel.x.3.|Butterworth.x.1.|Butterworth.x.2.|Butterworth.x.3.|ChebyshevI.x.1.|ChebyshevI.x.2.|ChebyshevI.x.3.|CriticalDamping.x.1.|CriticalDamping.x.2.|CriticalDamping.x.3.",fileNamePrefix="Modelica_3.2.3_Modelica.Blocks.Examples.Filter")
Notification: Performance of NFTyping.typeClassSections(Modelica.Blocks.Examples.Filter): time 0.007779/0.3953, allocations: 1.264 MB / 320.7 MB, free: 9.176 MB / 266.7 MB
Notification: Performance of NFFlatten.flatten(Modelica.Blocks.Examples.Filter): time 0.001012/0.3964, allocations: 233.8 kB / 320.9 MB, free: 8.949 MB / 266.7 MB
Notification: Performance of NFFlatten.resolveConnections(Modelica.Blocks.Examples.Filter): time 0.0001637/0.3966, allocations: 15.98 kB / 321 MB, free: 8.934 MB / 266.7 MB
Notification: Performance of NFEvalConstants.evaluate: time 0.0003943/0.397, allocations: 123.7 kB / 321.1 MB, free: 8.812 MB / 266.7 MB
Notification: Performance of NFSimplifyModel.simplify: time 0.0004736/0.3975, allocations: 135.4 kB / 321.2 MB, free: 8.68 MB / 266.7 MB
Notification: Performance of NFFlatten.collectFunctions(Modelica.Blocks.Examples.Filter): time 0.004059/0.4016, allocations: 1.03 MB / 322.2 MB, free: 7.648 MB / 266.7 MB
Notification: Performance of NFPackage.collectConstants: time 0.001162/0.4028, allocations: 92 kB / 322.3 MB, free: 7.559 MB / 266.7 MB
Notification: Performance of NFScalarize.scalarize(Modelica.Blocks.Examples.Filter): time 0.000385/0.4032, allocations: 99.72 kB / 322.4 MB, free: 7.461 MB / 266.7 MB
Notification: Performance of NFVerifyModel.verify: time 3.217e-06/0.4033, allocations: 4 kB / 322.4 MB, free: 7.457 MB / 266.7 MB
Notification: Performance of NFConvertDAE.convert(Modelica.Blocks.Examples.Filter): time 0.003807/0.4071, allocations: 1.435 MB / 323.9 MB, free: 6.02 MB / 266.7 MB
Notification: Performance of FrontEnd - DAE generated: time 7.895e-06/0.4072, allocations: 0 / 323.9 MB, free: 6.02 MB / 266.7 MB
Notification: Performance of FrontEnd: time 3.066e-06/0.4072, allocations: 4 kB / 323.9 MB, free: 6.016 MB / 266.7 MB
Notification: Performance of Transformations before backend: time 1.376e-05/0.4072, allocations: 0 / 323.9 MB, free: 6.016 MB / 266.7 MB
Notification: Model statistics after passing the front-end and creating the data structures used by the back-end:
 * Number of equations: 34
 * Number of variables: 34
Notification: Performance of Generate backend data structure: time 0.003004/0.4102, allocations: 0.771 MB / 324.6 MB, free: 5.199 MB / 266.7 MB

So, I understand the equation counting is performed in a kind of no man's land, which is located after the frontend and before the backend, whereby the data structure used by the backend from the results of the front-end is generated.

The question is: who is responsible for it? :)

[Karim Adbdelhak]

I tried to simulate the model from OMEdit and from command line using the old frontend and the new frontend and everything works fine. I can't recreate the problem...

From command line i used the latest master and in OMEdit i used 1.14.0~dev-26600-g7be26d6.

[Francesco Casella]

Replying to Karim.Abdelhak:

I tried to simulate the model from OMEdit and from command line using the old frontend and the new frontend and everything works fine. I can't recreate the problem...

From command line i used the latest master and in OMEdit i used 1.14.0~dev-26600-g7be26d6.

That's weird. I'm using OMEdit connected to OpenModelica v1.14.0-dev-26606-ge0b417b96a (64-bit) (latest nightly build) on Windows 10, using the attached .mo file. I reset OMEdit to the default settings, but I still get those errors.

I also run the attached .mos file from the command line, same effect.

[Karim Adbdelhak]

Ah sorry, i just forgot to use getErrorString(); and was led astray by OMEdit since it produced a result file.

I will have a short look later, maybe it is an easy fix!

[Per Östlund]

Replying to casella:

So, I understand the equation counting is performed in a kind of no man's land, which is located after the frontend and before the backend, whereby the data structure used by the backend from the results of the front-end is generated.

The question is: who is responsible for it? :)

Note that the line says "Model statistics after passing the front-end and creating the data structure used by the back-end". That message is coming from BackendDAECreate.lower, which is definitely in the backend.

We also have the CheckModel module though, which structurally is placed in the frontend and operates on the frontend DAE. That's what's used when you call checkModel, which is the reason why checkModel and the backend sometimes doesn't agree on the number of variables/equations. Ideally we'd have only one method of counting variables/equations, but that's another discussion.

[Karim Adbdelhak]

I created a pull request where toplevel inputs are considered unknown ​PR335. The proposed model works with this, lets see if it breaks anything.

[Francesco Casella]

As I commented in the pull request, it is only protected top-level inputs which should be considered as unknowns. They cannot be connected from the outside, so there is no "default equation" that applies to them, contrary to the case of public top-level inputs.

[Karim Adbdelhak]

I somehow messed up the first PR but the second ​PR338 went through and is ready to be pushed.

Feel free to close this ticket after you tested it for the full model.

[Francesco Casella]

Looks good.

Thanks @Karim!