Remove constant!

[HansOlsson]

This is a proposal to simplify the language.

The issue is that constant has varied a bit over the times, and currently it does not seem clear what benefits it brings compared to just parameters, and thus we can first deprecate it and view it as an alias for parameter. This becomes messier when we introduce evaluable parameters that sits between parameters and constants in some way.

Removing constant from the language would simplify the language, and allow us to use "constant" informally.

Package constants should be then be parameters, either final parameter (for pi, e, etc) or just parameter (in Modelica.Media); with the restriction that the used package-parameters outside models may not have fixed=false or transitively depend on parameters with fixed=false.

[eshmoylova]

Defining actual constants like pi as parameters does not seem right.

[henrikt-ma]

I love having a declared variability (constant) for things that can (normally) be assumed evaluatable during translation, instead of hiding away stuff in the Evaluate annotation. I also love the idea of having parameters that you declare as parameters, and that then end up being something that can be modified after translation, although I am fully aware that not all things declared parameter in Modelica fall into this category.

[henrikt-ma]

Of course, what I love and doesn't love is irrelevant here, and the comment above is missing the underlying reasons.

The main reason why I am so passionate about a clear separation between what is determined during translation and what is determined during initialization is that constant evaluation has such a profound impact on what equation systems one ends up solving during simulation. The more differences we can remove between what gets and what doesn't get evaluated during translation in different tools, the greater the chance that simulation results will be portable between tools, and this sort of portability is crucial to (but not the only aspect of) the goal of having a tool independent standard.

While achieving 100% portability of simulation results between tools may be a naive dream for some of the more demanding problems we are encountering from time to time, I think we must at least work in the direction of increased portability, not away from it.

With predicability of what gets evaluated during translation being so crucial to portability of simulation results, it is very good that one can at least declare something constant and (typically) expect it to be evaluated during translation and used for simplifications in the symbolic processing. To have control over what doesn't get evaluated during translation plays the same role for this predictability, and therefore a parameter with Evaluate = false is also an essential ingredient of a better future with more portable simulation results. I find it unfortunate that one has to fiddle with Evaluate in this way, but it seems to be a legacy that will be hard to get rid of.

[henrikt-ma]

One more reason for keeping constant is alignment with FMI, where there is also a distinction between constant and "fixed" variability (corresponding to parameter variability in Modelica). In FMI, the value of a constant can be accessed without even running the FMU, making constant very different from the other variabilities. Being able to declare an FMU constant as a constant in a Modelica FMI import wrapper is an example of good alignment of the two standards. Conversely, being able to control that a Modelica variable should become a constant in an exported FMU (allowing it to be accessed without running the FMU), by declaring it constant in the Modelica model, is another example of good alignment.

[HansOlsson]

Doesn't seem enough interest in it at the moment.