Parameter order in parameter dialog is sometimes not correct

[niklwors]

Description

For models derived from multiple classes, the order of parameters in the parameter dialog is not correct. The parameters of the base classes are not listed in the correct order. Often it is important that the parameters appear in the order in which they are declared in the model and base models.

Steps to Reproduce

Here is an example for this issue from our BRSL library:

Load the package Rexroth_Generic\package.mo
Drag and drop the component Rexroth_Generic.Hydraulics.Cylinders.DoubleRodCylinder onto a new sheet.
Open the parameter dialog of the cylinder

The order in the paramter dialog is:

dRodA
dPiston
dRodB
stroke
mPiston
g
contactDampingFactor

Expected Behavior

According to the inheritance hierarchy it should be:

dPiston
dRodB
stroke
mPiston
g
contactDampingFactor
dRodA

Screenshots

Version and OS

• OpenModelica Version: v1.21.0-dev-215-gfbc4a47daf
• OS: e.g. Windows 10, 64 bit
• MSL 4.0.0
• BRSL 2.2.1

Additional Context

[casella]

@niklwors, what do you mean by "correct parameter order"? In principle, the semantics of Modelica model is totally independent from the declaration order. Even more so when you have inheritance. What do you expect to get? First the base class defined parameters and then the child class defined parameters?

[niklwors]

Yes, we would expect them to appear in the same order as in the flattened model. The other Modelica tools using also this order.

[perost]

@niklwors, what do you mean by "correct parameter order"? In principle, the semantics of Modelica model is totally independent from the declaration order. Even more so when you have inheritance. What do you expect to get? First the base class defined parameters and then the child class defined parameters?

The parameters from extends should be inserted where the extends are. This is currently not the case with the instance API, it dumps extends and components separately. I don't remember why we designed it like that, but I guess we might have to rethink it.

The question is how to add that information to the JSON. I guess the most straightforward way is to just merge the components and extends into one array, but there are other ways if we want to avoid that. We could for example add "pointers" to the extends in the component array, or just have the information as a completely separate structure. It depends on what @adeas31 thinks is best for OMEdit.

[adeas31]

Why we have them in separate lists is because it makes sense when drawing. First we draw extends and then components.

For parameters I see that we need to maintain order as in the actual Modelica code. I always thought that we are suppose to list components first and then the extends.

@perost I think it doesn't matter what solution you pick since we anyway need to adapt OMEdit to it. So pick the solution that is best for JSON structure.