Need to manually insert "each" before fixed = false or true statement when initializing a vector

[gijs.schimmel@…]

When using an initialization such as a_0(start={0,0,0}) and clicking "fixed" in OMedit, the word "each" is not inserted in front of fixed = true. The translator/compiler does not accept this.

So it should read a_0(each fixed=true, start={0,0,0}), but OMEdit now inserts a_0(fixed = true,start={0,0,0}) everytime something is changed using the dialog of a MultiBody component.

It took me some time to guess I needed to insert "each" in front of the "fixed" keyword and it is annoying that I need to do that everytime whenever I use a dialog to change a parameter.

Applies at least to Modelica.Mechanics.MultiBody.Parts.Body

[casella]

Related to #5405. Basically, OMEdit still lack proper management of the each prefix. I tentatively make this and #5405 a blocker for 1.16.0, because this is really needed to use libraries such as MultiBody.

[Karim.Abdelhak]

This bug was also noticed in following StackOverflow question and it was mentioned that also some other things are disappearing after changing something in the Diagram View:

​StackOverflow - Save Initial Values

Copy paste of relevant information from that question:

But in case of discretized components, such as “pipe” it has to be done via “Text view” by using the operator each e.g. Q(each start = 0.3). However, the operator “each” disappears when one changes any parameter of the component via “Diagram view”, so it has to be given as follows:

• Q(start = {0.3 for i in 1:componentName.Ns+1})
• Q(start = fill(0.3, componentName.Ns+1))
• Q(start = {x1, x2, x3, x4, … xi})

Ns + 1 - for hydraulic nodes / Ns – for thermal nodes

PROBLEM

P.1.1 - Normally, one should write:

Q(start = fill(0.3, Ns+1), fixed = fill(true/false, Ns+1))

But it is the same story as with operator each, after changing any parameter of the component via “Diagram view”, the attribute fixed changes automatically to fixed=false, although an array is needed. I tried creating a Boolean parameter and using array comprehension but I always get the same outcome. Any advice or workaround?

[casella]

I guess the workaround in these cases is to only use the textual view for data input, which is of course ugly.

The proper solution is to implement this feature in OMEdit properly. I previously marked it as a blocker for 1.16.0, which is due next summer, maybe we can cram it in 1.15.0, if @adeas31 can work on it when he's back to work.

[casella]

Release 1.15.0 was scrapped, because replaceable support eventually turned out to be more easily implemented in 1.16.0. Hence, all 1.15.0 tickets are rescheduled to 1.16.0

[casella]

Retargeted to 1.17.0 after 1.16.0 release

[casella]

Rescheduled to 1.18.0

[casella]

Ticket retargeted after milestone closed

[casella]

1.18.0 blocker tickets moved to 1.19.0