Parameters without explicit start attribute modifiers should cause compilation to fail

[casella]

Description

MLS 3.5 Section 8.6 states:

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 value. In this case a diagnostic message is recommended in a simulation model.

So, according to MSL 3.5, this model should be rejected:

model M
  parameter Real p;
end M;

Unfortunately, OMC accepts it with a warning.

MLS 3.6 removed the default start attribute 0.0 from the predefined Real definition and accordingly changed the definition in 8.6:

If a parameter has a value 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 value for the start-attribute can be used to add a parameter binding equation assigning the parameter to that start value. In this case a diagnostic message is recommended in a simulation model.

but the net effect is the same.

Expected behaviour

Parameters with fixed = true and no binding equations or explicit start attribute modifiers should cause a model to be rejected.

[casella]

Adding @pierre-haessig to the loop.

[pierre-haessig]

For reference purpose, here are the starting points of the issue:

• Question on StackOverflow Parameter without default value in a Modelica model
• Parameter without default value in a Modelica model #10385

Thanks @casella for the explanation!

[pierre-haessig]

I've retested @casella Model example with parameter Real p; under OM 1.22.1 and it still simulates using a default value of 0.0.

[casella]

@phannebohm is this a quick fix?

[casella]

Also adding @ceraolo to the loop, this is critical for the PowerGrids library.

@phannebohm any thought on this issue? Is the backend aware of the difference between a Real having the default start value of zero and having any value (including zero) modified by a start attribute?

[phannebohm]

@phannebohm any thought on this issue? Is the backend aware of the difference between a Real having the default start value of zero and having any value (including zero) modified by a start attribute?

Yes, we can discriminate those cases. I opened #11805 which works as expected, on atomic MWEs at least.

This model fails to build:

model M1
  parameter Real p;
end M1;

"[/path/to/M1.mo:2:3-2:19:writable] Error: Parameter p has neither binding nor start value, and is fixed during initialization (fixed=true).
Error: No system for the symbolic initialization was generated
"

This model gives a warning but simulates with p = 0:

model M2
  parameter Real p(start = 0.0);
end M2;

"[/path/to/M2.mo:2:3-2:32:writable] Warning: Parameter p has no binding, and is fixed during initialization (fixed=true), using available start value (start=0.0) as default value.
"

This model simulates fine:

model M3
  parameter Real p = 0.0;
end M3;

""

The problem is, removing default start values apparently affects many other things too. I don't know what exactly goes wrong. Something generating the initial system. Maybe it's a quick fix. I'll have to investigate.

@kabdelhak we should implement this in the NB directly I guess.

[phannebohm]

Parameters with fixed = true and no binding equations or explicit start attribute modifiers should cause a model to be rejected.

Talking with @kabdelhak we noticed this might already be detected by the frontend. It does not depend on the rest of the system, only a single parameter needs to be looked at. @perost what are your thoughts on this?

[perost]

Parameters with fixed = true and no binding equations or explicit start attribute modifiers should cause a model to be rejected.

Talking with @kabdelhak we noticed this might already be detected by the frontend. It does not depend on the rest of the system, only a single parameter needs to be looked at. @perost what are your thoughts on this?

Yes, we could check that in the frontend. And we should probably also check constants, which are required to always have a binding equation.

Actually, can a constant even be non-fixed? It doesn't seem to be forbidden, but I'm not sure what that would even mean.