Improve inheritance of classes in MultiBody

[tobolar]

Closes #3739

[beutlich]

Happy to see #3725 (comment) addressed finally. Thanks!

[TManikantan]

@MartinOtter would you please review the fix?

[TManikantan]

@MartinOtter would you please review the fix?

[TManikantan]

@MartinOtter kindly review the fix

[MartinOtter]

ZeroForceAndTorque inherits from the new partial model Interfaces.PartialOneFrame_a which includes outer world. Howerver, in ZeroForceAndTorque, world is not used.
Therefore, it would be better to not inherit from a class, where elements are not used

The same holds for PartialTwoFrames: Again world is included, but submodels such as joints or force elements usually do not need world - so why include it?

[tobolar]

ZeroForceAndTorque inherits from the new partial model Interfaces.PartialOneFrame_a which includes outer world. Howerver, in ZeroForceAndTorque, world is not used.
Therefore, it would be better to not inherit from a class, where elements are not used

The background is that the base classes shall cover the following options:

• the world (yes/no)
• the "cardinality assert" (yes/no)

which would require a sum of 4 base classes for each "frame_a"-classes, "frame_b"-classes and "two_frames"-classes. So I tried to reduce the number of it but the drawback is there could be redundant elements.

I will try to improve the concept.

A related question: is it meaningful to introduce a base class which contains only "frame_a" and use it in nearly all components of the library?

[tobolar]

I will try to improve the concept.

What about to utilize the "selective model extension" and use PartialTwoFrames (containing both flange "a" and "b" and the world) instead of PartialOneFrame_a and PartialOneFrame_b. Each of the flanges or the world could then be deselected when inherited.
Is this a possible approach?

(I know, MSL is not yet fully compatible to Modelica Spec 3.6, but being just curious.)

[henrikt-ma]

(I know, MSL is not yet fully compatible to Modelica Spec 3.6, but being just curious.)

Nevertheless, that you bring up this question supports the idea of not formulating any constraints on how Modelica 3.6 may be used in #4208. Also, if you are interested in getting access to selective model extension in the MSL, then the best way to do it in my opinion is to set up a PR introducing the use of it, and then see how tool vendors react. The sooner the PR is created (and maybe even merged), the more time tool vendors will have to react before the code freeze, in turn increasing chances of not having to withdraw the change.

[HansOlsson]

(I know, MSL is not yet fully compatible to Modelica Spec 3.6, but being just curious.)

As far as I recall from the MAP-Lib meeting the idea for MSL 4.1.0 is to "Switch to Modelica Language 3.6 - but only use 3.6 annotations, and no other features (no new syntax, but new annotations)." #4175

Trying out "selective model extension" in a PR is still a good idea, even if it will not be included in that version.

[tobolar]

@HansOlsson @henrikt-ma Thanks for motivating myself to try this approach.

I believe the approach is possible, but is this also a case which was intended / expected when adding "selective model extension"? If yes, we will in the future iterate a ballance between a lot of simple base classes and a one mega-base-class.
So I will simply start a first try.

[tobolar]

I realized I have to prepare several particular PRs first.

[casella]

@tobolar it seems to me that this PR is still not mature enough to get into MSL 4.1.0. I am moving it to 4.2.0.