Tunable parameters don't exist according to specification

[henrikt-ma]

I recently received a complaint from someone trying to understand what a tunable parameter is. The person does have a background in FMI, and naturally turned to the Modelica specification for answers. However, what one finds in the specification (https://specification.modelica.org/master/class-predefined-types-and-declarations.html#component-variability) is just this (my emphasis):

A variable np declared with the parameter prefix, is called a non-evaluable parameter variable unless it is an evaluable parameter. It is also simply called a non-evaluable parameter. It does not change during transient analysis, with a value determined by the initialization problem. For further details, see 4.5.2.

Also, the linked section about parameters does not leave any room for tunable parameters.

I suggest that we reformulate slightly with tunability in mind, being well aware that there is currently no consensus about how to characterize the set of tunable parameters, or what it even means to tune a tunable parameter.

For example, something along those lines:

A variable np declared with the parameter prefix, is called a non-evaluable parameter variable unless it is an evaluable parameter. It is also simply called a non-evaluable parameter. It does not change during transient analysis, with a value determined by the initialization problem. For further details and tool-specific exceptions, see 4.5.2.

Details to give in 4.5.2, possibly as non-normative:

A variant of non-evaluable parameter which is in use, but with tool-dependent meaning, is tunable parameter (ADD TO DOCUMENT INDEX). Despite the rule that a parameter (evaluable or not) does not change during transient analysis, the idea is that some parameters still would be possible to change at events during transient analysis. When a tool identifies such parameters, they are often referred to as tunable parameters. Similar to other parameter component variabilities, some of the tunable parameters may be directly assigned at the events, whereas other tunable parameters will only be updated as a consequence of the direct assignments. Note that the criterion of being possible to change at an event, as well as the related the semantics of making a change, are tool-dependent.

We might even give a small example, but I think we need to keep it really simple to avoid discussing tool variations:

  parameter Real tau(unit = "s") = 1.0;
  Real x(start = 1.0, fixed = true);
equation
  tau * der(x) = -x;

If the existence of the tunable parameter concept is recognized by the specification, I also have a customer request to discuss. The customer would like an annotation for asserting that a particular parameter must be tunable. The use of the annotation is two-fold:

• Make it possible to detect that a parameter is not tunable already during translation, instead of when later failing to change the value.
• When detected during translation, the tool is in a much better position for providing the reason for non-tunability.

Instead of introducing this as a vendor-specific annotation, is Tunable = true something worth having in the standard? Of course, it should be formulated as something only applying to tools with the non-standard support for tunability. In my opinion, it would be a nice step in the direction of alignment with FMI. Would we expect problems due to tool variations to be an issue in practice?

[HansOlsson]

Interesting idea.

To me the main issues regarding tunable are (assuming the parameter is non-evaluated non-final parameter):

• Sometimes "tuning" a parameter is meaningless., like s_start below (assuming there are no other uses). It's kind of trivial for tools to detect this, but on the other hand it's more meaningless than incorrect.
• Related cases where the parameter is sent to an external object (etc); where updating everything depending on the parameter is too complicated.
• Sometimes "tuning" a parameter causes transient errors - like tau below, where one could say that x should be updated to compensate so that tau*x stayed the same. Tools cannot detect it for the case below, but if the model were written as der(tau*x)=-x; tools could detect that der(tau)=0 have been used and forbid tuning it. (This is a typical case for capacitors.)

  parameter Real tau(unit = "s") = 1.0;
  parameter Real s_start=1.0;
  Real x(final start = s_start, fixed = true);
equation
  tau * der(x) = -x; // Originally der(tau*x)=-x;

So, having Tunable=true would be useful and basically detect that we use der(param)=0. I'm not sure if we should also add Tunable=false, as it makes more sense to re-write the equations if possible.

[henrikt-ma]

You give three good examples of why we are not ready to go into any details about what tunability really should mean in Modelica.

Regarding Tunable = false, do you mean that Tunable should have the follow semantics?

• By default Tunable is neither false nor true.
• Tunable = true: Assert that parameter is classified as tunable, giving tools a chance to explain why a parameter sometimes cannot be tunable.
• Tunable = false: Require that a parameter is classified as non-tunable. This is a tool-independent input to the characterization of tunability. In principle, requiring that a parameter is non-tunable could enable symbolic simplifications which would not be possible if the tool aims for as much tunability as possible.

While it is neat to also have semantics for Tunable = false, I am not sure that it would add much value for users, especially since it requires pretty fancy symbolic treatment in tools to make a difference.

[HansOlsson]

Language group: Only describe tunable for 3.7, as there's a risk that different tools will interpret it differently.