Formalize 'evaluable parameter'

[henrikt-ma]

The need for formalization of evaluable parameter is far from new, and has recently come up again in different issues:

• #2602 – Clean definition of variability insides initial sections needs distinction between evaluable variability and parameter variability.
• #2742 – Acyclic binding rule gets quite complicated since it involves both evaluable and normal parameters.
• #2457 – Says evaluation of evaluable parameters is outside the specification, but we should be able to close the gap between specification and tools in this regard.

This PR proposes definitions of evaluable parameter and evaluable expression (corresponding variability) in a way that I hope is more or less in line with how these things work in tools already today (therefore hoping that this doesn't need to be considered MCP content). The three issues above are just some examples of things that would be clarified, making the specification easier to digest for uses, and more straight-forward to implement for tool makers.

At the time of setting up this PR, the changes are restricted to the following essential parts:

• Definition of evaluable parameter and normal parameter.
• Definition of evaluable expression (variability).
• Updated acyclic binding rule.
• Refined meanings of the Evaluate annotation.

Once we agree what these should be, it remains to update the specification to say evaluable expression rather than parameter expression everywhere something needs to be known at translation time.

I'd be interested to know what other tool makers are willing to share regarding support for these variants, in case that would reveal more things that should actually be locked down by the specification:

• Respecting Evaluate = false for a constant.
• Ensuring that no evaluated parameters without Evaluate = true are used in simplifications when verifying the acyclic binding rule.

Original formulation with structural parameter terminology

The rest of this comment shows what this first comment looked like before the change of terminology from structural parameter to evaluable parameter. It might be good to be aware of this original variant in order to be able to make sense of some of the subsequent comments…

The need for formalization of structural parameter is far from new, and has recently come up again in different issues:

• #2602 – Clean definition of variability insides initial sections needs distinction between structural variability and parameter variability.
• #2742 – Acyclic binding rule gets quite complicated since it involves both structural and normal parameters.
• #2457 – Says evaluation of structural parameters is outside the specification, but we should be able to close the gap between specification and tools in this regard.

This PR proposes definitions of structural parameter and structural expression (corresponding variability) in a way that I hope is more or less in line with how these things work in tools already today (therefore hoping that this doesn't need to be considered MCP content). The three issues above are just some examples of things that would be clarified, making the specification easier to digest for uses, and more straight-forward to implement for tool makers.

At the time of setting up this PR, the changes are restricted to the following essential parts:

• Definition of structural parameter and normal parameter.
• Definition of structural expression (variability).
• Updated acyclic binding rule.
• Refined meanings of the Evaluate annotation.

Once we agree what these should be, it remains to update the specification to say structural expression rather than parameter expression everywhere something needs to be known at translation time.

I'd be interested…

[perost]

In OpenModelica we define a parameter as structural if it must be evaluated by our frontend at compile time, such as a parameter used to define an array dimension in a simulation model. Your definition seem to be slightly different in that you define all parameters to be structural unless there's a reason for them not to be.

Our implementation is somewhat incompatible in this regard since we require structural parameters to have a binding equation that can be evaluated at compile-time, like constants, while you allow them to be given a value during initialization. Of course, OM is stricter in this case than the specification, so it could be considered a tool issue if this is something we want to allow.

Also, it seems to me like your definition is too broad for "structural" to be the correct word to use, since it will include a lot of parameters that don't actually affect the "structure" of the model. I don't have a better suggestion, but it's perhaps something to consider in order to avoid potentially confusing terminology.

[henrikt-ma]

In OpenModelica we define a parameter as structural if it must be evaluated by our frontend at compile time, such as a parameter used to define an array dimension in a simulation model. Your definition seem to be slightly different in that you define all parameters to be structural unless there's a reason for them not to be. … Also, it seems to me like your definition is too broad for "structural" to be the correct word to use, since it will include a lot of parameters that don't actually affect the "structure" of the model. I don't have a better suggestion, but it's perhaps something to consider in order to avoid potentially confusing terminology.

Yes, I know that the proposed nomenclature doesn't match exactly what many of us have in mind. I think it could be both good and bad to reuse terms that already have associate meanings outside the current specification:

• By finding a formal definition of structural parameter that we can unite behind, we might in the end be able to move away from a situation where the term is used differently in different tools.
• Of course, learning a new meaning for familiar term can also be quite challenging.

I should have said it from the beginning: What is commonly thought of as a "structural parameter" today, would in the current proposal translate into a (structural) parameter required by a structural expression (and as you noted, such a parameter has to be structural). Often, however, I believe that a more interesting classification is an evaluated structural parameter, which doesn't have to do with where the structural parameter is used, but emphasizing that this structural parameter is determined at translation time.

When choosing terminology, I'd like to start with the kind of expression variability that is required for things like array dimensions. Here, I think structural expression is a very natural name considering that we all seem to have some sort of "structural" in mind when it comes to these things. Then, we also need a name for a (more or less explicitly) declared variability associated with structural expression, and then structural parameter was the most natural I could think of.

Our implementation is somewhat incompatible in this regard since we require structural parameters to have a binding equation that can be evaluated at compile-time, like constants, while you allow them to be given a value during initialization. Of course, OM is stricter in this case than the specification, so it could be considered a tool issue if this is something we want to allow.

This sounds like a misunderstanding, unless this is only confusion due to reuse of terminology. The point is that just like today's "unqualified" parameters, a structural parameter does not have to be determined during translation, but the intention is really that a structural parameter is something as easy to evaluate at translation time as a constant. Wherever the specification requires a structural expression, all parameters involved will need to be structural, and will be possible to determine during translation. Hopefully, tools will be able to agree on which the structural parameters are (this PR might not be sufficient to really get us there), and then only differ when it comes to which of those that become determined during translation.

[henrikt-ma]

When choosing terminology, I'd like to start with the kind of expression variability that is required for things like array dimensions. Here, I think structural expression is a very natural name considering that we all seem to have some sort of "structural" in mind when it comes to these things. Then, we also need a name for a (more or less explicitly) declared variability associated with structural expression, and then structural parameter was the most natural I could think of.

To not only write in defense of the proposed nomenclature, let's make a list of alternatives:

	Expression variability	Component variability	Comment
1	structural expression	structural parameter	As currently proposed (approved by spell checker)
2	evaluatable expression	evaluatable parameter
3	constish expression	constish parameter	It's almost like a constant (German vibes, anyone?)

[MartinOtter]

I only scanned this pull request due to lack of time (and maybe missed essential points):

If this proposal is just for making the specification clearer without changing existing models (and the existing semantics of the Modelica language), this is of course good. However, I fear that you plan to introduce restrictions on the language that are currently not present, and this in a core part of the language that is present in nearly every model, at least if arrays are declared. Please, can you confirm, that the current semantics of the Modelica language is not changed with your proposal and that it will not have any effect on existing models.

[henrikt-ma]

I only scanned this pull request due to lack of time (and maybe missed essential points):

If this proposal is just for making the specification clearer without changing existing models (and the existing semantics of the Modelica language), this is of course good. However, I fear that you plan to introduce restrictions on the language that are currently not present, and this in a core part of the language that is present in nearly every model, at least if arrays are declared. Please, can you confirm, that the current semantics of the Modelica language is not changed with your proposal and that it will not have any effect on existing models.

The goal is to specify this in a way that doesn't require changing existing models, at least as long as one stays away from models that exhibit tool specific corner case behaviors. For example, since none of the MSL models should depend on such tool specific behaviors, it should work just like as before.

Trying to summarize implications for semantics (let's assume https://github.com/modelica/ModelicaSpecification/pull/2754#discussion_r537859744 is accepted):

• Criterion for being a structural parameter is in some ways more liberal (and easier to check) than the old acyclic binding rule.
• Non-fixed parameters are not structural, whereas it used to be possible to have them evaluated (see example below).
• Refined meanings of the Evaluate annotation by taking advantage of separation of normal and structural parameters, giving users better control over what is and what isn't determined during translation.

Example of changed semantics for non-fixed parameter:

model M
  parameter Integer p = 1;
  parameter Integer n(fixed = false);
  /* Before, this wasn't illegal, since there was no rule against solving for n at translation time,
   * and force evaluation of p.
   * Now, this becomes illegal, since n is a normal parameter.
   */
  Real x[n];
initial equation
  n = p + 1;
end M;

[henrikt-ma]

If people don't agree about the implications of this proposal it is clear that we need to change it.

Yes. I am doing my best to identify any implications causing disagreement, and find ways to adapt the proposal. The proposal is in Draft state for good reasons. :)

[eshmoylova]

I feel like the proposal states that it wants to clarify the issues while it actually introduces a new feature. The main point that I take away upon reading this is that it is allowed to have parameters with cyclic bindings. However, I did not find the explanation of how the cycles are to be resolved. If there is one, please point it out to me. This is a major change. It my not break any existent models because they would follow the rule for acyclic bindings but it would make many models that are now considered illegal to be legal. To me personally, the rule of acyclic bindings in parameters has been the norm for such a long time that calling parameters that break this rule normal does not sit right with me.

There are other specific comments that I have that I will submit later inline.

[henrikt-ma]

I feel like the proposal states that it wants to clarify the issues while it actually introduces a new feature. The main point that I take away upon reading this is that it is allowed to have parameters with cyclic bindings. However, I did not find the explanation of how the cycles are to be resolved. If there is one, please point it out to me. This is a major change. It my not break any existent models because they would follow the rule for acyclic bindings but it would make many models that are now considered illegal to be legal. To me personally, the rule of acyclic bindings in parameters has been the norm for such a long time that calling parameters that break this rule normal does not sit right with me.

This seems to be a common concern. The reason the change ("new feature") ended up in the proposal was that I thought the purpose of the acyclic binding rule was to make parameters similar to constants, so that they would be easy to evaluate during translation. Now, with separation of structural and normal parameters, it felt natural to me to only keep the requirement where it is motivated for technical reasons.

Even with the current acyclic binding rule, a parameter with declaration equation can end up being solved in mysterious ways (see https://github.com/modelica/ModelicaSpecification/pull/2742#issuecomment-737492229), so I wouldn't consider a parameter abnormal just because it isn't solved in a simple fashion. To me, the "normal" thing for a parameter is that it is determined during initialization.

As others have also pointed out, however, there are reasons beyond the technical ones why one would like to further constrain also the normal parameters with declaration equations, trying to capture the intuition about certain things being solved in a simple fashion. Since one can often (let's not get into details here) avoid the acyclic binding rule by using an initial equation instead of a declaration equation, this doesn't harm expressiveness much, and it is clear to me now that this is what will be needed to have a chance of getting the proposal accepted. Still I'd like to avoid going back to the exact same acyclic binding rule that we had before, because of its intricate and unclear consequences when non-fixed parameters are involved.

As mentioned in comments above, I see two easy ways to get back the essence of the old intuition about parameters with declaration equation. If possible, I'd like to try to resolve this by making a poll with alternatives:

1. Error if there is a cycle involving only fixed = true parameter declaration equations (using structural parameter values to break cycles) – a new and improved acyclic binding rule for parameters.
2. Warn if fixed = true parameter declaration equation ends up in a system of equations.
3. Error + warning.
4. Neither: Generally allow cycles involving normal parameters (as currently proposed).
5. Just rephrase old acyclic binding rule for normal parameters.

[eshmoylova]

As mentioned in comments above, I see two easy ways to get back the essence of the old intuition about parameters with declaration equation. If possible, I'd like to try to resolve this by making a poll with alternatives:

I spent a lot of time looking at the poll options trying to make sense of them and, as far as I can see, every option covers only part of the concerns I have.

1. Error if there is a cycle involving only fixed = true parameter declaration equations (using structural parameter values to break cycles) – a new and improved acyclic binding rule for parameters.

Does not answer the issue of what to do when fixed = false and there are cycles in the modifications and there are no initial equations.

2. Warn if fixed = true parameter declaration equation ends up in a system of equations.

How would it end up in the system of equations? Does not answer the question of cycles.

3. Error + warning.
4. Neither: Generally allow cycles involving normal parameters (as currently proposed).

Not defined how to resolve cycles.

5. Just rephrase old acyclic binding rule for normal parameters.

I would need to know what exactly needs to be rephrased and how to be able to decide whether this is a good option.

[henrikt-ma]

@eshmoylova, GitHub doesn't let me answer to some of your comments within the conversation, so I quote your https://github.com/modelica/ModelicaSpecification/pull/2754#discussion_r540394025 here instead:

A warning does not clarify to me how to interpret that expression, as Hans said. One may choose to interpret it as r = 2 * sin(r.start).

OK, maybe we have different intuitions about this. My intuition is that it would be the same as making the parameter fixed = false and interpret the declaration equation as an initial equation. (I can't see how one would end up with the interpretation using r.start.)

However, if we would include the rule of option 1 in the poll, this example would simply be illegal, which I believe is what you would prefer.

[henrikt-ma]

As mentioned in comments above, I see two easy ways to get back the essence of the old intuition about parameters with declaration equation. If possible, I'd like to try to resolve this by making a poll with alternatives:

I spent a lot of time looking at the poll options trying to make sense of them and, as far as I can see, every option covers only part of the concerns I have.

1. Error if there is a cycle involving only fixed = true parameter declaration equations (using structural parameter values to break cycles) – a new and improved acyclic binding rule for parameters.

Does not answer the issue of what to do when fixed = false and there are cycles in the modifications and there are no initial equations.

I'd like to avoid debating this case, since a fixed = false parameter with declaration equation should result in a warning already today. I don't think we can count on this being handled equally across tools today, so I think we should try to avoid adding the complexity of making it clearly defined as part of this PR.

2. Warn if fixed = true parameter declaration equation ends up in a system of equations.

How would it end up in the system of equations? Does not answer the question of cycles.

Due to mutual dependency on other parameters. This alternative in the poll does not forbid the cycles – the cycles just prove that the parameters involved in the cycle aren't structural. See alternative 3.

3. Error + warning.

Now, for a fixed = true parameter to end up in a cycle, it must have escaped the acyclic binding rule (of alternative 1) by mutual dependency on a parameter without binding equation.

4. Neither: Generally allow cycles involving normal parameters (as currently proposed).

Not defined how to resolve cycles.

The equations in a cycle are simply included in the initialization problem, just as one would have done if the parameters had fixed = false. I suppose this could be clarified if we would go with this alternative.

5. Just rephrase old acyclic binding rule for normal parameters.

I would need to know what exactly needs to be rephrased and how to be able to decide whether this is a good option.

Maybe just change "parameter" to "normal parameter"? (Structural parameters would still be acyclic by definition.) Really, I don't know. The point of this alternative is to do as little design as possible and simply ignore some of the problems that this PR wants to address. Something including the rule of alternative 1 seems so much better to me, that I hope we won't need to write out alternative 5 in more detail.

[henrikt-ma]

As there haven't been any comments suggesting that a rule like in alternative 1 would be too restrictive, I plan to update the proposal with this rule. Hopefully, this will remove some of the worst concerns, and then we can look at the details of this rule, and whether to combine it with additional warnings.

[henrikt-ma]

I am happy with the proposal as it is.

Can you see that this would also work for #2602?

[qlambert-pro]

I am happy with the proposal as it is.

Can you see that this would also work for #2602?

Yes, hence my comment. Once we have the structural parameter formalized, we can have a better definition of initial sections. One that does not require exceptions on variability checking.

[HansOlsson]

Looking more I see two and a half additional issues:

One is that the new terminology is not yet used in most places where it should be used, e.g. if-equations with unequal number of equations in the branches currently require a parameter-expression - that should be a structural expression; as the intent is that parameter-expression is evaluated - which doesn't work for a normal parameter expression. Other similar cases are (possibly complete list): first argument to smooth, the if-condition on a component declaration, array dimensions, expression of for-expression, for/if conditions controlling when-equations, assertionLevel to assert, for-equations, first argument to cat, and parameter expression in clocked chapter; and subscripts in arguments to pre, left-hand-side variables in equations, and in connect.

The half one is that this implies that arrays and subscripting in functions wouldn't work with these restrictions. To me the logical conclusion is that variables in functions behave as structural parameters, see later. Unfortunately this will be a bit messed up for assertionLevel and cat inside functions; I assume we just have to live with allowing more.

The second is that we currently informally use "structural parameter" for parameters that are evaluated for structural reasons, whereas this defines something that can best be described as "potential structural parameters" with current terminology; that is parameters that we could evaluate for structural reasons if necessary.

One possibility would just be to note this; another would be to rethink and rename it as "Evaluable parameter" (or something similar) and use that consistently, which means the current "structural parameter" is just an "evaluable parameter" that we had to evaluate for structural reasons.

And back to functions: to say that everything in functions behave as if it is "Structural" doesn't make so much sense, but viewing it as "Evaluable" sort of works as we do evaluate the functions by providing values for all inputs when calling it.

[henrikt-ma]

One is that the new terminology is not yet used in most places where it should be used, e.g. if-equations with unequal number of equations in the branches currently require a parameter-expression - that should be a structural expression; as the intent is that parameter-expression is evaluated - which doesn't work for a normal parameter expression. Other similar cases are (possibly complete list): first argument to smooth, the if-condition on a component declaration, array dimensions, expression of for-expression, for/if conditions controlling when-equations, assertionLevel to assert, for-equations, first argument to cat, and parameter expression in clocked chapter; and subscripts in arguments to pre, left-hand-side variables in equations, and in connect.

This is by intention. Before updating the document to use the new terminology there needs to be agreement on what to change. I also wanted to delay making the changes to keep the PR diff smaller while we discuss the concepts, and to avoid unnecessary merge conflicts.

By the way, it's great that you've already provided the possibly complete list of places to update!

[henrikt-ma]

The second is that we currently informally use "structural parameter" for parameters that are evaluated for structural reasons, whereas this defines something that can best be described as "potential structural parameters" with current terminology; that is parameters that we could evaluate for structural reasons if necessary.

One possibility would just be to note this; another would be to rethink and rename it as "Evaluable parameter" (or something similar) and use that consistently, which means the current "structural parameter" is just an "evaluable parameter" that we had to evaluate for structural reasons.

Naming, always naming. :)

To me, the more important of the two concepts is what is called structural parameter in the current formulation. The tool-dependent evaluated parameter seems less important, with very few uses in the specification. Since "structural parameter" is a widely recognized but only a vaguely defined thing today, I found it best to give it a formal definition now, and to define it as the more important of the two concepts. I also find evaluated parameter a very clear name for a parameter that has been evaluated, for whatever reason.

One should also keep the naming of the corresponding expression variability in mind. I don't find evaluable expression a very good term, as "evaluable" seems too generic in this formulation, and I find the three part name evaluable parameter expression too cumbersome when the other expression variabilities have names with only two parts.

[henrikt-ma]

The half one is that this implies that arrays and subscripting in functions wouldn't work with these restrictions. To me the logical conclusion is that variables in functions behave as structural parameters, see later.

Yes, this was missed. Fixed in commit.

Unfortunately this will be a bit messed up for assertionLevel and cat inside functions; I assume we just have to live with allowing more.

Can you explain?

[HansOlsson]

The second is that we currently informally use "structural parameter" for parameters that are evaluated for structural reasons, whereas this defines something that can best be described as "potential structural parameters" with current terminology; that is parameters that we could evaluate for structural reasons if necessary. One possibility would just be to note this; another would be to rethink and rename it as "Evaluable parameter" (or something similar) and use that consistently, which means the current "structural parameter" is just an "evaluable parameter" that we had to evaluate for structural reasons.

Naming, always naming. :)

To me, the more important of the two concepts is what is called structural parameter in the current formulation. The tool-dependent evaluated parameter seems less important, with very few uses in the specification.

To me this is mixing two concepts. The important part of the current specification are some evaluated parameters, currently called "structural parameters"; although the exact definition is a bit fuzzy. However, even if fuzzy we know that there lots of other parameters that could in theory be evaluated - but they aren't important.

The logic is that changing them changes the structure of the model, and since we cannot handle varying structure that means that they must be evaluated.

So we have three sets: structural<evaluated<evaluable (see as sub-set instead of less-than); and this PR formalizes evaluable; not structural. We might find a better name for it, but at least we need to understand this distinction.

[henrikt-ma]

After verifying that @qlambert-pro plan to attend the upcoming phone meeting, I added this PR to the milestone. (It was on the agenda last time, but then we didn't discuss it because neither @qlambert-pro nor @eshmoylova was present.) @eshmoylova, does this sounds like a good plan to you too?

[HansOlsson]

To give an intuitive explanation of the various parameters I can think of the following categories. The names might be changed, but it's important to understand these differences:

• Translation evaluable parameters; parameters that could be evaluated during the translation to literal values.
• Translation evaluated parameters; parameters that have been evaluated during the translation to literal values.
• Structural parameters; parameters that clearly impact the structure - number of variables, DAE index, etc
• Semi-structural parameters; parameters where some values impact the structure (normally DAE index); typically these are Real variables where zero or some other value is important.

Some examples: Translation evaluable parameter (and depending on code maybe also evaluated):

parameter Integer n=1,m=2*n;
parameter Real x=cos(2);

Structural parameter:

  parameter Integer n=1;
  parameter Boolean b=true;
  Real x[n];
  Real y;
equation
 if b then
    der(y)=time-y;
 else
   y=time;
  end if;

Semi-structural parameter:

  parameter Real alpha=0;
  Real y;
equation
  alpha*der(y)=time-y;

Note that we can generate code without evaluating a semi-structural parameter (and sometimes even structural parameter), it's just that if we try to change it the model will cease to work (for any change of a structural parameter, and for some changes for a semi-structural one). So normally they form a hierarchy of sorts.

Note that "semi-structural parameters" isn't as clear-cut category as the other and sometimes the structural change will happen for combinations of several parameters.

[henrikt-ma]

To give an intuitive explanation of the various parameters I can think of the following categories. The names might be changed, but it's important to understand these differences:

Yes, it's important to be aware of these categories, but it's also good to understand that this PR is focusing on the need for a formalization of just one new variability, between constant and a normal parameter. While I've found it helpful to define the notion of an evaluated parameter, I am hoping that we can get what we need for the new variability without formalizing what you call "structural parameter" and "semi-structural parameter".

[eshmoylova]

I agree that it would be better to discuss this PR in the language group meeting before adding more commits. Barring any other family emergencies, I should attend the next design meeting.

Couple other thoughts I had while looking at the last comments. In @HansOlsson's example of the structural parameters.

Structural parameter:

  parameter Integer n=1;
  parameter Boolean b=true;
  Real x[n];
  Real y;
equation
 if b then
    der(y)=time-y;
 else
   y=time;
  end if;

I find that b is structural in the sense that it changes the structure of the system but I do not think that we absolutely need to evaluate it at the translation time. If it was guarding some connect statements:

if b then
  connect(c1.y,c2.x);
else
  connect(c2.y,c1.x);
end if;

then we would have to evaluate it at the translation time. So we have yet another categories: structural and needed at the translation time.

In view of that, I think, it might be good to revisit again what we try to formalize and why. My understanding was that we want to have a term for what I and Hans understand as "evaluable" parameters. Then in the appropriate places in the specification we can say that the expressions can be evaluated at the translation time. There are additional changes in this PR that are related to that but might confuse the matter a bit. There are the proposed changes to the Evaluate annotation (including applying it to constants). I feel like some of those changes are more related to how we view parameters after translation: can we change them in the flattened model and still have structurally the same model? I feel like that merits its own discussion (and probably its own name).

[henrikt-ma]

So we have three sets: structural<evaluated<evaluable (see as sub-set instead of less-than); and this PR formalizes evaluable; not structural. We might find a better name for it, but at least we need to understand this distinction.

To understand the name structural expression (and structural parameter) currently used in this PR, one must think of this as an expression that can be used for structure-changing ("structural") properties. What a tool actually evaluates is less important from language design point of view, which is why the term structural parameter is not used in this sense.

Again: part of the naming problem is that I sense an expectation that the currently undefined term structural parameter should be given a formal meaning, and I've found it better to use it for the more important concept from (language formalization point of view), than to introduce a new term. I can see that the PR may seem a bit incomplete if it doesn't even address the question of what to call a structural parameter that a tool decided to evaluate in order to avoid structure-changing parameters in the translated model. We could also call this a structure-changing parameter/expression for the sake of this discussion, but no matter what we call it, it could be better to not introduce this term in the specification. Instead, we could just non-normatively emphasize that an evaluated parameter isn't necessarily something affecting model structure; what a tool needs to evaluate to avoid dealing with varying structure is a quality of implementation, and the variability structural expression only makes it clear what a tool may evaluate to lock down model structure.

[HansOlsson]

I agree that it would be better to discuss this PR in the language group meeting before adding more commits. Barring any other family emergencies, I should attend the next design meeting.

Couple other thoughts I had while looking at the last comments. In @HansOlsson's example of the structural parameters.

Structural parameter:

  parameter Integer n=1;
  parameter Boolean b=true;
  Real x[n];
  Real y;
equation
 if b then
    der(y)=time-y;
 else
   y=time;
  end if;

I find that b is structural in the sense that it changes the structure of the system but I do not think that we absolutely need to evaluate it at the translation time.

True, it depends on the rest of the model and what solver you use.

If you want to simulate it using an ODE-solver, then you clearly need to know whether der(y) appears or not; since that determines whether y is a state or algebraic variable and thus you need to evaluate it; but if you use a general DAE-solver you might avoid evaluating it for some implementations. However, the way we designed the DAE-solver in Dymola we would still need to evaluate it.

[eshmoylova]

It was just pointed out to me that in FMI there is calculatedParameter:

"calculatedParameter": A data value that is constant during the simulation and is computed during initialization or when tunable parameters change

That would roughly correspond to how "normal" parameters are defined in this PR. Perhaps "normal" parameters as defined in this PR should be called "calculated parameters" for consistency.

I think it is worth discussing the names at the next meeting since we did not get around to it at the previous meeting. So I do not suggest making any further changes at this moment but just wanted to record this idea while I remember it.

[henrikt-ma]

(Oh, how I wish there was a way to keep a conversation like this organized in the same way as when discussing a line of code in the PR!)

"calculatedParameter": A data value that is constant during the simulation and is computed during initialization or when tunable parameters change

That would roughly correspond to how "normal" parameters are defined in this PR. Perhaps "normal" parameters as defined in this PR should be called "calculated parameters" for consistency.

I don't think that we should use that term, as it's meaning is too different. If we leave tunable parameters aside, you can see that being a "calculated parameter" means being a parameter (determined during initialization) with either appriximate or calculated initializability, whereas just being a (FMI) "parameter" means being a parameter (determined during initialization) with fixed initializability. Hence, the "calculated" part of the term is about narrowing down the initializability. The normal parameters in the PR can have all three initializabilities (even though we don't call them by name in Modelica):

• Fixed: parameter Real x = 1.0;
• Calculated: parameter Real x(fixed = false); initial equation x = 1.0;
• Approximate: Calculated: parameter Real x(fixed = false, start = -1.0); initial equation x^2 = 1.0;

[HansOlsson]

It was just pointed out to me that in FMI there is calculatedParameter:

"calculatedParameter": A data value that is constant during the simulation and is computed during initialization or when tunable parameters change

That would roughly correspond to how "normal" parameters are defined in this PR. Perhaps "normal" parameters as defined in this PR should be called "calculated parameters" for consistency.

I would say they are different, but they are still important for getting the terminology right.

To get consistent terminology we have:

 parameter Real p=2; // Normal parameter, evaluable (as we can evaluate p)
 parameter Real p2=p*2; // Dependent parameter (as it depends on p)

An evaluable parameter, p, can be evaluated or not.

If p is tunable (i.e. not evaluated) then:

 parameter Real p2=p*2; // Calculated parameter for FMI

If p is evaluated (i.e. not tunable) then:

 parameter Real p2=p*2; // Also evaluated parameter

There is no need to differentiate between primary and dependent evaluated parameters after translation as they are just values that don't change.

[henrikt-ma]

To get consistent terminology we have:

 parameter Real p=2; // Normal parameter, evaluable (as we can evaluate p)
 parameter Real p2=p*2; // Dependent parameter (as it depends on p)

An evaluable parameter, p, can be evaluated or not.

After a period of mostly working on less profound issues, I'd like to come back to this one. Would the proposal seem more appealing if terminology was switched from structural to evaluable?

[henrikt-ma]

If p is tunable (i.e. not evaluated) then:

I don't think tunable and evaluated is opposites, even though being evaluated clearly excludes being tunable.

If p is evaluated (i.e. not tunable) then:

 parameter Real p2=p*2; // Also evaluated parameter

That's not a valid assumption in general. Just because p2 can be evaluated, it doesn't imply that it will be. In this case, evaluating it would remove the possibility to change it after translation, so evaluation even has semantic impact. Had p2 been marked final, evaluation shouldn't affect the semantics (but one can never rule out unforeseen consequences of symbolic simplifications enabled by constant evaluation), but it would still be up to the tool to decide whether to evaluate (unless forced for reasons no seen here).

There is no need to differentiate between primary and dependent evaluated parameters after translation as they are just values that don't change.

True, and for the specification the most important aspect is to identify which parameters to call evaluable, and where in the specification an expression is required to be evaluable.

If we change terminology from structural to evaluable, I think we should still include a non-normative description of the typical meaning of structural and how it relates to evaluable:

• A parameter (expression) that determines model structure that a tool is unable to modify after translation is often referred to as a structural parameter (expression). To ensure compliance with the specification, a tool may only rely on evaluation of such a parameter (expression) when the specification requires it to be evaluable.