Connector appearance and naming harmonisation in MSL 4.0.0

[max-privato]

if I understand well, in the upcoming MSL 4.0 it will be allowed to insert non-backward compatible enhancements.
It this is true, this is an opportunity to add some changes that in principle improve the library, but in practice are impossible in 3.x releases to avoid breaking existing models and libraries.

In this context, I have a few considerations and a proposal.

There is an important analogy between the electrical component OnePort and mechanical (translational and rotational) component PartialCompliant.
In particular, both have connectors with one flow and one potential variable, and an internal variable that is the difference between the two connectors potentials.

In the case of electrical one port-based components, this difference variable is p.v-n.v, i.e. the difference of the potential of the internally filled connector and the internally empty one.
In the case of mechanical one port -based components this difference is flange_b.phi- flange_a.phi or flange_b.s- flange_a.s. i.e. the difference of the potential of the internally empty connector and the internally filled one.

So, mechanical and electrical libraries show two following inconsistency:
1) the roles of the filled and empty connectors are reversed

Looking closer at the various connectors we find inconsistencies:

• connectors in Electrical.Analog.basic are named "p" and "n"
• connectors in Electrical.MultiPhase are named "plug_p" and "plug_n"
• connectors in Electrical.QuasiStationary.basic are named "pin_p" and "pin_n"
• mechanical are named flange_a_ and flange_b

i.e. the have the following inconsistencies:
2) In some cases connectors carry in their name just the quality of being assumed positive or negative, in other cases also the quality of being a pin or a plug.
3) In mechanical libraries just 'a' and 'b' are used, while in electrical libraries the sign semantics is included with the usage of 'p' and 'n'

I think that "p" and "n" carry more information than "a" or "b", and therefore should be in principle preferred also in mechanical systems. Even if the polarity concept is more common with electric circuits than mechanical systems, what here matters (for me) is that the role of polarity in this context is just to indicate how you use connector potential variables to compute internal differences, and this is in common in mechanical and electrical cases.

So I have two proposals that I express below. Proposal 1 tries to address all inconsistencies. Proposal 2 tries to address only inconsistency 1.

Proposal 1 comes in two versions, 1a and 1b. For me, they are rather equivalent, since both hare pros an cons. In case of need, however, I can contribute more to this comparison at a later time.

---

Proposal 1a : naming and order of connectors
(actions are in italic)

• in mechanical rotational and mechanical translational fill the connector at present internally empty and use for it the name "p" (instead of di "flange_a")
• in mechanical rotational and mechanical translational empty the connector at present internally filled and use for it the name "n" (instead of "flange_b")
• in Electrical.MultiPhase and Electrical.Quasistationary name the filled connector "p" instead of "plug_p" and "pin_p", repsectively
• in Electrical.MultiPhase and Electrical.Quasistationary name the empty connector "n" instead of "plug_n" and "pin_n", respectively

Proposal 1b : naming and order of connectors
(actions are in italic)

• in mechanical rotational and mechanical translational fill the connector at present internally empty and use for it the name "flange_p" (instead of di "flange_a")
• in mechanical rotational and mechanical translational empty the connector at present internally filled and use for it the name "flange_n" (instead of "flange_b")
• in Electrical.Analog.Basic name the filled connector "pin_p" instead of "p"
• in Electrical.Analog.Basic name the empty connector "pin_n" instead of di "n"

Proposal 2: ordering of connectors

According to this proposal, the flange_a connector of mechanical (rotational and translational) libraries should become internally empty and flange_b internally filled (respectively with grey and green colours)

---

My ideal priority is to adopt proposal 1a or 1b. In case this does not receive enough favour, I propose at least to adopt my proposal 2.

Just to keep Francesco informed: @casella

[HansOlsson]

This is an issue for ModelicaStandardLibrary not - for the specification.
Will attempt to fix that.

[tobolar]

See
#2481 for more connectors` discrepancies and
#2997 for "analogy between the electrical component OnePort and mechanical (translational and rotational) component PartialCompliant".

Concerning mechanical components, I suppose a typical user's approach is to think in real mechanical dimensions. No potential, no energy flow. If there is a spring, it could be easily interpreted that frame_a is fixed and frame_b is moved in positive direction, thus generating a negative force pressing the spring back. This is simply straightforward.

I suppose this is also the reason why the Mechanics library deals with Newton-Euler approach rather then some energetic principles.