Add rule for allowing fixed parameters to be unbound during translation

[henrikt-ma]

Closes #2952.

This PR is the continuation of #2962 that didn't go in the direction of addressing the problem which #2952 was all about, namely the portability between tools of simulation models containing unbound parameters.

Regarding the recommended diagnostic for the new situation, I imagine that System Modeler would actually not give any diagnostic when translating a model for the Wolfram Language context where it it natural to provide all parameter values when starting the simulation. During a "traditional" build, however, giving a diagnostic would make more sense as it might be considered cumbersome to have parameters that must be provided later.

[henrikt-ma]

Note on implementation

A minimal implementation could represent the unbound parameter status using an internal built-in expression. For example,

model M
  parameter Real p;
  parameter Integer k;
end M;

can be handled internally by flattening the model as:

model M
  parameter Real p = __SomeToolName_replaceme_Real("x");
  parameter Integer k = __SomeToolName_replaceme_Integer("k");
end M;

where "x" and "k" are the flattened names of the unbound parameters.

At runtime, the __SomeToolName_replaceme_Real("x") will simply abort the simulation with an error explaining that x must be given a value.

(As the expression actually doesn't evaluate to anything, it could be sufficient to just have a single kind of replaceme-expression. Whether this is an appealing alternative will depend on tool-specific type-checking details.)

[HansOlsson]

This mixes different issues, and they should first be listed and then untangled:

Previously there were in fact two different issues:

• The simulation requirement, which #2962 tried to address, without mentioning the other issue. The unmentioned part was the reason for the specific example in that PR.
• No rule for unbound parameters: As far as I can see there is currently no specific rule for parameters without any value in a simulation model (and without start etc). In my opinion that is at least as wrong as having a start-value as default for a parameter. (It is assumed in the specification in section 5.6.2. Dymola still checks it; and thus MSL doesn't have any parameters without a value. ) Clearly specifying that is good, but it is a separate issue from what a simulation model means.

I'm not sure how the new simulation requirement here differs from the one in #2962 - obviously this also adds the rule for unbound parameters.

What I find unclear in this PR:

• For parameter Real R(start=2) can a tool allow you to change R before solving the initialization problem? (Is such a modification allowed for any parameter?)
• If you change the parameters before solving the initialization problem why is a diagnostics still recommended?

[henrikt-ma]

This mixes different issues, and they should first be listed and then untangled:

Previously there were in fact two different issues:

• The simulation requirement, which Clarify simulation requirement #2962 tried to address, without mentioning the other issue. The unmentioned part was the reason for the specific example in that PR.

Yes, and in my opinion the generality of such a formulation made it too hard to grasp what it would come down to in various situations. We might still be able to work out something like that later, even if it wouldn't provide the kind of fix we're seeking for #2952.

• No rule for unbound parameters: As far as I can see there is currently no specific rule for parameters without any value in a simulation model (and without start etc). In my opinion that is at least as wrong as having a start-value as default for a parameter. (It is assumed in the specification in section 5.6.2. Dymola still checks it; and thus MSL doesn't have any parameters without a value. ) Clearly specifying that is good, but it is a separate issue from what a simulation model means.

I agree that it is at least as wrong, and while there is currently no specific rule, I see this as a consequence of the perfect matching rule; each variable needs to be solvable in some equation, and fixed parameter without a declaration equation can currently only be saved by the start-attribute trick.

I'm not sure how the new simulation requirement here differs from the one in #2962 - obviously this also adds the rule for unbound parameters.

The main difference is the focus on requiring that the value is provided explicitly (and the non-normative part explains why this is essential).

Another difference is that this PR targets precisely the problem of #2952 instead of something general with consequences that are hard to grasp.

What I find unclear in this PR:

• For parameter Real R(start=2) can a tool allow you to change R before solving the initialization problem? (Is such a modification allowed for any parameter?)

Are you referring to the point that it doesn't have an explicit setting of fixed = true? Isn't changing parameter values before solving the initialization problem what we normally do with most parameters? Or do you mean that while we do it, it isn't stated clearly in the specification that one can?

• If you change the parameters before solving the initialization problem why is a diagnostics still recommended?

Because I imagine that the need to explicitly specify parameter values after translation could cause an inconvenience that the user wants to become aware already during build. By not requiring a diagnostic, the model can still be translated silently in situations where providing all parameter values after translation is standard procedure.

[HansOlsson]

• For parameter Real R(start=2) can a tool allow you to change R before solving the initialization problem? (Is such a modification allowed for any parameter?)

Are you referring to the point that it doesn't have an explicit setting of fixed = true? Isn't changing parameter values before solving the initialization problem what we normally do with most parameters? Or do you mean that while we do it, it isn't stated clearly in the specification that one can?

It wasn't about fixed = true, but that the rules for parameters with neither start nor value clearly stated that you could change them - but if you have a start-value there was nothing about changing it. This is sort of related to the next item.

• If you change the parameters before solving the initialization problem why is a diagnostics still recommended?

Because I imagine that the need to explicitly specify parameter values after translation could cause an inconvenience that the user wants to become aware already during build. By not requiring a diagnostic, the model can still be translated silently in situations where providing all parameter values after translation is standard procedure.

To me this depends so much on the different use-cases that I would prefer to leave that entirely to the tools - so that we don't have to argue whether the recommendations can be ignored or not in certain cases; or at most say that tools may give diagnostics already when translating.

As an example consider running a parameter sweep for some parameters. In that case the tools could know that the parameter will be changed (to different values as part of the sweep), and thus there's clearly no need for a warning during translation. And if the parameter isn't part of the ones that are changed, it is an error.

[eshmoylova]

I don't see how this addresses the issue of models portability. From what I understood during the phone meeting, the main issue with #2962, that you (@henrikt-ma) had was that a model with parameters that have neither binding equations nor start-values would work in your tool but fail in another. I do not see how what you propose addresses that. Such a model would still be an incomplete model. You still need a way of saying these are parameters that should be set before simulation and these are their values. Sure, by identifying the parameters with no binding equations and no start values a tool may figure out what parameters it needs to request from a user before the simulation. But it still needs values. Will they come in some text file that user is going to manually input? Will the user just know what values are supposed to be? Then the model is only portable together with the user.

[henrikt-ma]

To me this depends so much on the different use-cases that I would prefer to leave that entirely to the tools - so that we don't have to argue whether the recommendations can be ignored or not in certain cases; or at most say that tools may give diagnostics already when translating.

As an example consider running a parameter sweep for some parameters. In that case the tools could know that the parameter will be changed (to different values as part of the sweep), and thus there's clearly no need for a warning during translation. And if the parameter isn't part of the ones that are changed, it is an error.

The specification currently uses three different strengths with regards to diagnostics: must, may, and recommends. To seek a compromise, I have now changed it from recommends to may. The reason is that I would be very disappointed if my tool didn't give me a warning when this happens in a situation where isn't clear that values will be provided later, and I think it would give the wrong impression if the specification didn't say anything about the good idea of informing users about potential problems when it is time to start simulation.

[henrikt-ma]

• For parameter Real R(start=2) can a tool allow you to change R before solving the initialization problem? (Is such a modification allowed for any parameter?)

Are you referring to the point that it doesn't have an explicit setting of fixed = true? Isn't changing parameter values before solving the initialization problem what we normally do with most parameters? Or do you mean that while we do it, it isn't stated clearly in the specification that one can?

It wasn't about fixed = true, but that the rules for parameters with neither start nor value clearly stated that you could change them - but if you have a start-value there was nothing about changing it. This is sort of related to the next item.

The formulation doesn't say change, it says provide. I think this is the way to go unless we want to get into the tricky business of defining exactly which parameters that will be possible to change after translation, especially before we even have a formalization of evaluable parameter to work with.

[henrikt-ma]

I don't see how this addresses the issue of models portability. From what I understood during the phone meeting, the main issue with #2962, that you (@henrikt-ma) had was that a model with parameters that have neither binding equations nor start-values would work in your tool but fail in another. I do not see how what you propose addresses that. Such a model would still be an incomplete model. You still need a way of saying these are parameters that should be set before simulation and these are their values. Sure, by identifying the parameters with no binding equations and no start values a tool may figure out what parameters it needs to request from a user before the simulation. But it still needs values. Will they come in some text file that user is going to manually input? Will the user just know what values are supposed to be? Then the model is only portable together with the user.

It should be left to tools to find ways to ensure that the values are explicitly provided. A model can be translated into many different target formats, and each format may have its own ways of parameterization. In System Modeler, for example, we have something that reminds of the modelDescription.xml in FMI, where we could make the difference between parameters having a value and those that must be explicitly provided. This would allow the simulation user interface to keep track of these, so that dummy values are not automatically injected. In addition to that, there needs to be a check somewhere that none of the required values are missing, and while it might require least work to check this inside the simulation executable, it would likely give a better user experience if the check was made directly in the simulation user interface (so that "clicking simulate" isn't possible until all values have been provided).

Maybe it would be good for illustration to include an example around FMI export? The FMI standard has no concept for required parameter values, and as far as I understand, start is a required attribute for fixed parameters. Hence, a parameter value is required already at the time of translating the model. In this case, the tool must conclude that since the condition of explicitly provided values cannot be checked later, it must be treated as an error during translation.

[HansOlsson]

If that sentence is not correct then it should be stated that it is enough to specify the start on the type, but start values of builtin types should not be considered as "provided".

To me (as previously suggested) the simplest suggestion for fixing that would be to remove the start-values of the builtin types.

[henrikt-ma]

If that sentence is not correct then it should be stated that it is enough to specify the start on the type, but start values of builtin types should not be considered as "provided".

To me (as previously suggested) the simplest suggestion for fixing that would be to remove the start-values of the builtin types.

I suggest that we try to do this separately, and with minimum changes to terminology. When can then look into a change of terminology as a second step.

[HansOlsson]

If that sentence is not correct then it should be stated that it is enough to specify the start on the type, but start values of builtin types should not be considered as "provided".

To me (as previously suggested) the simplest suggestion for fixing that would be to remove the start-values of the builtin types.

I suggest that we try to do this separately, and with minimum changes to terminology. When can then look into a change of terminology as a second step.

That was done for 3.6, which makes this PR outdated and it might be best to restart it.

[henrikt-ma]

That was done for 3.6, which makes this PR outdated and it might be best to restart it.

No need to restart; I just need to update with the new terminology.

[HansOlsson]

That was done for 3.6, which makes this PR outdated and it might be best to restart it.

No need to restart; I just need to update with the new terminology.

With the addition of "fallback value" I'm not sure if this is PR is needed.

[henrikt-ma]

With the addition of "fallback value" I'm not sure if this is PR is needed.

Aha, so a consequence of introducing fallback values was that this is now supposed to be a valid simulation model?

model M
  parameter Real p;
  annotation(experiment(StopTime = 1.0));
end M;

Then the introduction of fallback values was a much bigger change than I realized, as I really liked the old requirement that all parameters must be given values unless they explicitly use the start-attribute trick.

[HansOlsson]

With the addition of "fallback value" I'm not sure if this is PR is needed.

Aha, so a consequence of introducing fallback values was that this is now supposed to be a valid simulation model?

model M
  parameter Real p;
  annotation(experiment(StopTime = 1.0));
end M;

Then the introduction of fallback values was a much bigger change than I realized, as I really liked the old requirement that all parameters must be given values unless they explicitly use the start-attribute trick.

No, that model should still not work. It took me a bit of time to check, but:

• Fallback value is used when there is no start-attribute and the start-value normally should be used.
• The special case for parameters without a value explicitly require a value for the start-attribute: "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."

However, this PR may still need updating based on that decision.

[HansOlsson]

However, this PR may still need updating based on that decision.

Change that to: "this PR need updating based on that decision." (It is also the cause of the merge conflict.)

There's also the issue of how to achieve the goal of portability between tools of simulation models containing unbound parameters; when translated models aren't really portable between tools (unless we consider FMI, and as far I can see from FMI 3 parameters must have a value in the XML-file - which seems contrary to this idea.)

#2962 was an attempt to allow both tools that fail already during translation, and tools that delay the check until the simulation (or even allow both as different tool-settings).

[henrikt-ma]

There's also the issue of how to achieve the goal of portability between tools of simulation models containing unbound parameters; when translated models aren't really portable between tools (unless we consider FMI, and as far I can see from FMI 3 parameters must have a value in the XML-file - which seems contrary to this idea.)

Right, this is complicated. The case of producing an FMU would be an exception, as it is easy to simply reject models with unbound parameters in this case. The desire for portability between tools is what lies behind #2952, and I don't imagine the solution to be neither easily designed nor easily implemented.