Allow for modifiers in translateModel() and simulate() API functions

[Francesco Casella]

It is often the case that one wants to run batches of simulations where some parameters are changed, in order to explore the configuration space. For this purpose, it would be nice if one could write modifiers directly in the simulate() and translateModel() functions, e.g.:

simulate(MySystem(component2(T = 10)))

This feature is provided by Dymola and it is indeed very useful in such cases.

[Martin Sjölund]

How about:

loadString("model M
  parameter Real p=1;
  Real x1(start=p);
equation
  der(x1) = 1.0;
end M;");getErrorString();
simulate(M,simflags="-override p=5");getErrorString();
plot(x1);

[Francesco Casella]

This is nice, but it doesn't work for structural parameters, e.g.

loadString("model M
   parameter Integer N = 4;
   Real x[N](start = linspace(1,N,N), each fixed = true);
 equation
   der(x) = x;
 end M;");getErrorString()

simulate(M,simflags="-override N=10")

plot(x[10])

An important application is when you need to change the number of nodes/volumes in a distributed parameter model, and see how many nodes are enough to get an accurate result.

[Adrian Pop]

I'll be taking care of this.

[Martin Sjölund]

Milestone pushed to 1.9.5

[Martin Sjölund]

Milestone renamed

[Martin Sjölund]

Ticket retargeted after milestone closed

[Francesco Casella]

I understand you can implement

simulate(M(p=10, redeclare M2 m), ...);

where p is a structural parameter, by doing this:

loadString("
model M_modified;
  extends M(p=10, redeclare M2 m);
end M_modified;

simulate(M_modified, ....);

which is only slightly inconvenient because

• you need to know this programming pattern
• the default name for the simulation results is X_res.mat and not M_res.mat

Could we implement this trick internally in the simulate() API, making it transparent to the user? You just need to take the content of the model name input, build the string that declares the modified model, load it and use it to generate the simulation code, and use the original model name as a default for the -r option. Seems quite easy to do.

The only tricky part I see would be that the filenames of all generated code will not refer to M but rather to M_modified. Maybe that's not a big deal, and maybe that can also be taken care of easily.

[Adrian Pop]

The name can be changed with simulate(M_modified, simflags="-r Model_res.mat");

[Martin Sjölund]

Replying to adrpo:

The name can be changed with simulate(M_modified, simflags="-r Model_res.mat");

More common I suspect is simulate(M_modified, fileNamePrefix="Model");, which causes all files generated to have the prefix of "Model".

[Francesco Casella]

So it seems that

simulate(M(p=10, redeclare M2 m), ...);

can be obtained by running

loadString("
model X;
  extends M(p=10, redeclare M2 m);
end X;

simulate(X, ....);

In fact this is almost true, save that the experiment annotation of model M is lost when extending it, which is of course critical.

Suggestions?

[Martin Sjölund]

Milestone moved to 1.12.0 due to 1.11.0 already being released.

[Francesco Casella]

Moved to milestone 1.13.0 as milestone 1.12.0 was closed

[Francesco Casella]

The milestone of this ticket has been reassigned to "Future".

If you think the issue is still valid and relevant for you, please select milestone 1.13.0 for back-end, code generation and run-time issues, or 2.0.0 for front-end issues.

If you are aware that the problem is no longer present, please select the milestone corresponding to the version of OMC you used to check that, and set the status to "worksforme".

In both cases, a short informative comment would be welcome.

[Francesco Casella]

See discussion in #6014