Changing string parameters between simulations

[ceraolo]

A very useful feature in OMEdit is the possibility to change parameters once the model is built and re-run, which often requires just a fraction of the time needed for a full build-and-run.

However, string parameters are not available in Variables Browser, thus cannot be changed.

An important case in which changing a string parameter between runs of the same build is very useful occurs when we load data in a table from a file.
In this case, in case the string defining the file name could be changed from the Variables Browser, getting data from a different file at each re-run would require just changing the file name, and be fast and effective.
Currently this is impossible.

[adeas31]

Willi, is this possible?

[wbraun]

I do not see any issue, actually it's even possible now via -override

For instance:

model TestString
  parameter String s = "Test String Param";
  Real x;
equation
  der(x) = 2*x+1;
  when x>0.5 then
    terminate(s);
  end when;
end TestString;

One can run:
./TestString -override s="Override Test"
what will override the string parameter.

[adeas31]

But for the GUI you have to mark the string parameter isValueChangeable in the model_init.xml.

[wbraun]

Replying to adeas31:

But for the GUI you have to mark the string parameter isValueChangeable in the model_init.xml.

It is marked as isValueChangeable already.

[adeas31]

Sorry my bad guys.....the problem is that we don't list string parameters in the Variables Browser and that is because the list of variables is read from result file using ​readSimulationResultVars.

[adeas31]

Martin, is it a good idea to include string parameters in the result file.

[sjoelund.se]

We would need to change result-file format in that case. I don't belive the later versions of the dsres format has it. There is also a problem in that string matrices take space proportional to the longest string in the matrix.

[casella]

There are also other problems with dsres: when you use Complex variables, the text in the comment of the Complex variable (a record) itself, which explains what the variable actually means, is lost, and what you see in the variables browser are the re and im fields with the dumb comment "Real part" and "Imaginary part", see #5309.

This issue should also be addressed, as it is quite serious if you use Complex numbers extensively.

[ceraolo]

Replying to sjoelund.se:

There is also a problem in that string matrices take space proportional to the longest string in the matrix.

I would be totally satisfied if just the name (without path) is shown in the variables browser, and therefore stored in the result file.
So this should not impact the result file size.

I suppose that this name's size should be compared with the length of the strings we already write on the output file, to find the longest, which determines the string matrix size. For instance for a resistor we write:

Temperature coefficient of resistance (R_actual = R*(1 + alpha*(T_heatPort - T_ref)) [1/K]

which is longer than any reasonable name we might think of (without path).

Anyway, even in case this is not true, names without paths should not have significant impact on the output file size.

[casella]

Releasing 1.14.0 which is stable and has many improvements w.r.t. 1.13.2. This issue is rescheduled to 1.16.0

[casella]

After some discussion with @adeas31 during yesterday's webmeeting, we figured that this could be improved by having OMEdit read those values from the XML file, instead of from the result file.

Maybe this could also fix #5309, without any need to change the Dymola-esque result file format.

[casella]

Retargeted to 1.17.0 after 1.16.0 release

[casella]

Retargeted to 1.18.0 because of 1.17.0 timed release.

[adeas31]

Done in dfb3a7a/OpenModelica.

[ceraolo]

well done!