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 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.
• 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.

[HansOlsson]

Overall it looks good, but there are some minor issues as indicated in my latest comment.

[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]

I would just remove this line, as it seems like such an odd idea to guard against.

Suggested change

Note that the requirement must not be fulfilled by defaulting to something like the default value for the parameter's type, as this would bypass the intention that all parameters should be determined either by the model itself or by the user of the translated model.

[eshmoylova]

I think it is an important point, which is actually not clear in the specification right now. What is meant by "providing start-attribute"? Consider the following example:

type RealStart = Real(start = 10);

model M
    model MM
        Real x;
	parameter RealStart p;
    equation
        x = p;
    end MM;

    MM mm;
end M;

I tried it in MapleSim, Dymola and OpenModelica. It simulates, giving a warning that the default values is used. But is it correct to consider that the start value is given? I scanned through units in MSL. There is only ThermodynamicTemperature that has start value specified on type. But then there is a bunch of types that extend from it. So, if somebody has a parameter of ThermodynamicTemperature type and does not specify the start attribute when that instance is defined (and no modification given at any point later), do we consider that the start-attribute is provided or not? With the sentence that Henrik added, it should not be considered as provided. But it is treated as such right now but at least 3 tools. 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".

[henrikt-ma]

To me, this line is at the heart of the proposal. I don't want this proposal to end up removing the current rule that all parameters must be given a value – either directly or using the start attribute to bypass the rule.

In @eshmoylova's example above, the intention is to consider p as having start-attribute, meaning that the sentence we're discussing here doesn't apply. Hence, I don't understand this comment:

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".

There should be no special rule about being considered "provided". Provide start, and you bypass the mechanism to guard against use of uninitialized parameters. To ensure that parameters are given values by users of a model one must not provide start, neither directly nor via the use of a type alias.

[HansOlsson]

Instead of discussing "modifier for start-attribute" I believe we should:

• Write "the start-attribute has a value".
• Remove the default value for the start-attribute in the built-in types such as Real, Integer, ... as it does not really make sense in the light of this section. Claiming that RealStart=Real(start=0) has a modifier for the start-attribute, but Real with RealType start=0; lacks it, seems weird. This is also consistent with this PR removing the "non-zero" text.

We also have to consider the following odd cases for start-attributes (assuming MCP0009 is accepted):

model U
 parameter Real x(final start);
 parameter Real y(start=break);
end U;

Both of them arguably has a modifier for the start-attribute, but neither has a value for the start-attribute.
(Using final on a modifier without providing a value is well-defined semantically, but normally it is used when you already have a value, in order to finalize that.)

[HansOlsson]

I would just remove this line, as it seems like such an odd idea to guard against.

I was hoping for some feedback on removing this.

Additionally I realized that apart from being an odd idea, I don't understand what it means.

How do we determine the default value for the parameter's type? The obvious idea would be to use the start-value of the type, but in that case the parameter has a start-value and the sentence does not apply.

[henrikt-ma]

Instead of discussing "modifier for start-attribute" I believe we should:

I believe this would need to be discussed in a separate issue to avoid scope creep. Some things to keep in mind when working out such a proposal:

• It would be easy to state that start = break is not a modifier, but removes an existing modifier.
• We also need terminology for what is now called the default value of the type, which is where the RealType start = 0 can come into play.

[henrikt-ma]

I would just remove this line, as it seems like such an odd idea to guard against.

I was hoping for some feedback on removing this.

Additionally I realized that apart from being an odd idea, I don't understand what it means.

I gave feedback above: #3075 (comment)

The purpose is to not break a big hole in the current safety net for ensuring that all parameters must have a value when a model is simulated.

[eshmoylova]

Marking as "request changes" to make sure I get to look at how the comments get resolved before it gets merged.

[eshmoylova]

I think it is an important point, which is actually not clear in the specification right now. What is meant by "providing start-attribute"? Consider the following example:

type RealStart = Real(start = 10);

model M
    model MM
        Real x;
	parameter RealStart p;
    equation
        x = p;
    end MM;

    MM mm;
end M;

I tried it in MapleSim, Dymola and OpenModelica. It simulates, giving a warning that the default values is used. But is it correct to consider that the start value is given? I scanned through units in MSL. There is only ThermodynamicTemperature that has start value specified on type. But then there is a bunch of types that extend from it. So, if somebody has a parameter of ThermodynamicTemperature type and does not specify the start attribute when that instance is defined (and no modification given at any point later), do we consider that the start-attribute is provided or not? With the sentence that Henrik added, it should not be considered as provided. But it is treated as such right now but at least 3 tools. 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".

[HansOlsson]

Suggested change

	A parameter not having \lstinline!fixed = false! and neither having a binding equation nor being part of a record having a binding equation, is handled in different ways depending on the presence of a modifier for the \lstinline!start!-attribute.
	If there is no modifier for the \lstinline!start!-attribute, it is an error unless a parameter value is explicitly provided before solving the initialization problem.
	In this case, a tool may give a diagnostic message when translating a simulation model to inform the user that additional parameter values must be provided later.
	If there is a modifier for the \lstinline!start!-attribute, the modifier can be used to add a parameter binding equation assigning the parameter to that \lstinline!start! value.
	A parameter not having \lstinline!fixed = false! and neither having a binding equation nor being part of a record having a binding equation, is handled in different ways depending on whether its \lstinline!start!-attribute has a value or not.
	If there is no value for the \lstinline!start!-attribute, it is an error unless a parameter value is explicitly provided before solving the initialization problem.
	In this case, a tool may give a diagnostic message when translating a simulation model to inform the user that additional parameter values must be provided later.
	If the \lstinline!start!-attribute has a value, it can be used to add a parameter binding equation assigning the parameter to that \lstinline!start! value.

Like this.

[henrikt-ma]

I get the point, wouldn't it be too much scope creep to try to switch terminology as part of this PR?

[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.