Evaluate all parameters except some

[Francesco Casella]

I am trying to optimize the code generation and the runtime performance of large power grid models compiled with OMC. These models have a very large number of parameters, most of which will never need to be changed at runtime. If I set -d=evaluateAllParameters I can have them evaluated to literal constants in the front-end, with great benefits in terms of improved back-end optimizations, reduced back-end running time, reduced code size and improved runtime performance.

However, we need in fact to be able to change just a handful of parameters at runtime, that typically describe the simulation scenario: which loads are changing, which breakers are opened, etc. Unfortunately, this is currently not possible if -d=evaluateAllParameters is set.

Putting the Evaluate=true annotation on the parameters that are not going to change is impractical, and also it adds an unnecessary restriction to possible future uses of the model that require the parameters not to be evaluated, e.g. for sensitivity analysis.

So, I would propose to add the flag --evaluateAllParametersExcept=regexp to the NF, that evaluates all the parameters in the front-end, except those matching the regexp.

@perost, how long would it take to implement such a functionality?

[Per Östlund]

What about marking parameters that should be changeable with Evaluate=false, and have -d=evaluateAllParameters evaluate all parameters except those? That would certainly be easier to implement at least. The NF doesn't respect either the Evaluate annotation nor the evaluateAllParameters flag at the moment, but that would be fairly easy to implement.

[Francesco Casella]

That's one possibility. It is a bit inconvenient from an end-user point of view: if, for example, the changeable parameter is the amplitude of a Modelica.Blocks step signal generator, AFAIK it is not possible to mark it with this annotation.

I guess this could be managed by defining extra parameters at the top level of the model with Evaluate=false for those parameters and then using them as modifiers for the Modelica.Blocks parameters, right? This would be ok.

[Per Östlund]

Replying to casella:

I guess this could be managed by defining extra parameters at the top level of the model with Evaluate=false for those parameters and then using them as modifiers for the Modelica.Blocks parameters, right?

I'm not sure how well that would work. I was thinking of just marking all parameters as structural when evaluateAllParameters is set, which would cause them to be evaluated during the typing phase. But having a structural parameter depend on a parameter with Evalute=false would be problematic (the compiler should warn about that, or maybe even give an error).

But we can always just add another phase somewhere that evaluates parameters based on the flags given. Would it be needed to handle array elements separately, i.e. should it be possible to exempt for example a[3] from evaluation but evaluate all other elements of a? From an implementation point of view it doesn't really matter, it's just a matter of performance whether it should be done before or after scalarization.

[Francesco Casella]

Replying to perost:

Would it be needed to handle array elements separately, i.e. should it be possible to exempt for example a[3] from evaluation but evaluate all other elements of a?

I don't think so.

The requirement for the models I have in mind is that there are a tens of thousands of parameters that should be evaluated, and just a handful of parameters that shouldn't. If a few more are not, that's no big deal, as long as the tens of thousands are. It's just a matter of quantity, not of critical evaluations for symbolic manipulation such as in MultiBody. So, keeping the same Evaluate attribute for an entire array of parameters is just ok.