Opened 6 years ago

Closed 4 years ago

Last modified 4 years ago

#5177 closed enhancement (fixed)

Changing string parameters between simulations

Reported by: massimo ceraolo Owned by: Adeel Asghar
Priority: normal Milestone: 1.18.0
Component: OMEdit Version:
Keywords: Cc: Willi Braun, Martin Sjölund

Description (last modified by massimo 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.

Change History (16)

comment:1 by massimo ceraolo, 6 years ago

Description: modified (diff)

comment:2 by Adeel Asghar, 6 years ago

Cc: Willi Braun added

Willi, is this possible?

comment:3 by Willi Braun, 6 years ago

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.

comment:4 by Adeel Asghar, 6 years ago

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

in reply to:  4 comment:5 by Willi Braun, 6 years ago

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.

comment:6 by Adeel Asghar, 6 years ago

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.

comment:7 by Adeel Asghar, 6 years ago

Cc: Martin Sjölund added

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

comment:8 by Martin Sjölund, 6 years ago

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.

comment:9 by Francesco Casella, 6 years ago

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.

Last edited 6 years ago by Francesco Casella (previous) (diff)

in reply to:  8 comment:10 by massimo ceraolo, 6 years ago

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.

comment:11 by Francesco Casella, 5 years ago

Milestone: 1.14.01.16.0

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

comment:12 by Francesco Casella, 4 years ago

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.

comment:13 by Francesco Casella, 4 years ago

Milestone: 1.16.01.17.0

Retargeted to 1.17.0 after 1.16.0 release

comment:14 by Francesco Casella, 4 years ago

Milestone: 1.17.01.18.0

Retargeted to 1.18.0 because of 1.17.0 timed release.

comment:15 by Adeel Asghar, 4 years ago

Resolution: fixed
Status: newclosed

comment:16 by massimo ceraolo, 4 years ago

well done!

Note: See TracTickets for help on using tickets.