Opened 12 years ago

Closed 10 years ago

Last modified 7 years ago

#2188 closed defect (fixed)

Handling of arrays in the plot window needs improvement in OMEdit

Reported by: Per Östlund Owned by: Adeel Asghar
Priority: normal Milestone: 1.9.4
Component: OMEdit Version: trunk
Keywords: Cc:

Description

When displaying the result plot in OMEdit it seems like component names are split at dots to build a variable tree. I.e. 'a.b' and 'a.c' becomes a node 'a' with children 'b' and 'c'.

However, component names in Modelica can actually contain dots if they are quoted, i.e. Real 'a.b'. Enumeration literals used as subscripts also contain dots, i.e.:

model M
  type E = enumeration(one, two);
  Real x[E] = {1, 2};
end M;

results in the components x[E.one] and x[E.two]. This causes OMEdit to create a node 'x[E', with children 'one' and 'two'.

So the parsing of component names needs to consider these cases, i.e. don't split names inside quotes or brackets. Even though it's by mistake I like the way that array elements with enumeration subscripts are grouped together right now, and think it would make sense to always group array elements. I.e. an array Real x[2] would result in a node 'x' with children '1' and '2', similarly to what MDT does for arrays and lists.

Change History (5)

comment:1 by Per Östlund, 11 years ago

Seems like somethings been broken since OMC now thinks the example model is structurally singular. A workaround is to simply move the bindings to an equation section:

model M
  type E = enumeration(one, two);
  Real x[E];
equation
  x = {1, 2};
end M;

comment:2 by Adeel Asghar, 11 years ago

Priority: highnormal
Status: newaccepted

r17151. I have just grouped the array elements event the two dimensional array elements are grouped as one like this,

a := {{1, 2, 3}, {4, 5, 6}};

a
->[1,1]
->[1,2]
->[1,3]

instead of,

a
->[1]
->->[1]
->->[2]
->->[3]
->[2]
->->[4]
->->[5]
->->[6]

For now its fine. I will make it more better later on.

comment:3 by Adeel Asghar, 10 years ago

Resolution: fixed
Status: acceptedclosed

comment:4 by Dietmar Winkler, 9 years ago

Milestone: Futurepre1.9.4

It doesn't make sense to keep closed ticket in the "Future" milestone that were simply forgotten to assign to the correct milestone in the past.

comment:5 by Martin Sjölund, 7 years ago

Milestone: pre1.9.41.9.4

Removing the pre1.9.4 milestone in favor of 1.9.4.

Note: See TracTickets for help on using tickets.