Are simulation annotation actually meant to only use literal constants?

[casella]

The simulation annotations introduced in Section 18.4 are defined with literal values: UNSIGNED-NUMBER or (true | false).

Some tools actually allow to use parameters to specify those values, similarly to what is possible with the GUI annotations defined in Section 18.7. For example, running

model M
  parameter Boolean hide = true;
  Real x = sin(time) annotation(HideResult = hide);
end M;

in Dymola doesn't show x in the results browser. However, this behaviour seems not to be according to the standard.

Q1: Is there any design rationale behind the fact that annotations in 18.4 can only have literal values, while annotations in 18.7 can also have expression values?

Q2: should we allow expressions in the simulation annotations in MLS 3.7, or rather deprecate their use in existing tools?

[casella]

Adding @perost, @AndreaBartolini to the loop.

[maltelenz]

See also #1672 and #3133

[HansOlsson]

This enhancement in Dymola was (in addition to #1672 ) mentioned in #2754 (comment) (yes, both Evaluate and HideResult can take evaluable parameter expressions); and the idea was to revisit it after
#2754 was merged (e.g., now).

It is not case of something accidentally working in Dymola, but due to user requests.

For graphical objects (I assume you mean section 18.6 not 18.7) it is somewhat different, as we need to consider potential errors (and/or other failures to evaluate parameters) and thus using DynamicSelect makes more sense (so that there's a default value).

Extending this to experiment (in particular stop-time) would be possible (I think), even though the request are usually framed in the opposite way (using the stop-time in the model to set some parameter).

Extending it to many other annotations is less clear, and to me some of the uses would indicate some other need that we first need to look at.

[henrikt-ma]

Extending this to experiment (in particular stop-time) would be possible (I think), even though the request are usually framed in the opposite way (using the stop-time in the model to set some parameter).

Yes, an evaluable expression could be a first step for StopTime. On top of that, one could also imagine allowing it to be a parameter expression, and it would be interesting to hear which of these variants that @casella had in mind?

[HansOlsson]

Extending this to experiment (in particular stop-time) would be possible (I think), even though the request are usually framed in the opposite way (using the stop-time in the model to set some parameter).

Yes, an evaluable expression could be a first step for StopTime. On top of that, one could also imagine allowing it to be a parameter expression, and it would be interesting to hear which of these variants that @casella had in mind?

A parameter (non-evaluable) expression for StopTime seems both complicated and not general enough.

We have terminate to stop the simulation in the general case, where the stop-time isn't even a parameter expression - whereas an evaluable expression mean that we can provide progress bars etc. And for start-time I simply don't see a good way to handle a non-evaluable expression.

[AndreaBartolini]

I just would add a real use-case regarding the HideResult annotation.
I built a complex model in that I can selectively turn on/off the visualisation and, more important, the storage in the .mat file, of some groups of variables by using a bolean array parameter that selectively set the HideResult annotation of said groups of variables.
The main goal is to reduce the size of the .mat file for users that are interested in only one (or few) goup of the said variables (the complete .mat file has a dimension of hundreds of MB).
I cannot figure out an alternative way to obtain the same behavior, any suggestion is appreciated.

[casella]

I agree with @AndreaBartolini's comment. Though there could potentially be some application for parameter-depending StopTime, applications needing that can readily use terminate().

The use-case requirement here is to be able to selectively include or exclude saving and showing simulation results by means of parameters, so it's basically only meant for HideResult.

[henrikt-ma]

This enhancement in Dymola was (in addition to #1672 ) mentioned in #2754 (comment) (yes, both Evaluate and HideResult can take evaluable parameter expressions); and the idea was to revisit it after
#2754 was merged (e.g., now).

While HideResult sounds trivial to make evaluable, I can see a challenge when it comes to Evaluate due to the the role it plays for the definition of being evaluable. After some initial discussion like this, I recommended proceeding with small PRs for one or a small number of related annotations at a time.

For the general discussion, what are the variabilities of importance for annotations? Is it constant, evaluable, and continuous-time (no constraint on variability)? Or do we also need some annotations to something else, such as literal expressions or parameter expressions?

[HansOlsson]

Separate PR for HideResult and Evaluate.