Add units to outputs of quasi static electrical sensors

[christiankral]

Units are added to the real output signals of the Analog.Sensors. Even though some tools are able to deduce the correct units from the equations, this may not be implemented in all tools yes. There is, however, no discrepancy in adding units to the outputs of sensors, as long as they are correct.

For the quasi static power and multi sensors, the complex output power has units which may be more difficult to be determined automatically:

• unit of real part of complex output power = "W"
• unit of imaginary part of complex output power = "var"
  From a formal point of view both units are equal to "VA" (Volt*Amps), but typically, electrical engineers distinguish the units "W" and "var".

Therefore, it makes sense to add units to the complex outputs of quasi static sensors including the power sensors. This allows:

• the correct specification of the active and reactive power
• support tools which are not yet fully capable of determining the units of a calculation

This ticket is related with #2488.

[AHaumer]

see #2494 (and #2488), let's continue the discussion on a generalized level in #2494.

[christiankral]

Considering c641a86 it seems possible to at least add units to the signal outputs of the quasi static electrical sensors. Even though ticket #2494 was closed, I suspect I can add the units (not quantities) to the respective signal outputs. @beutlich do you agree?

[christiankral]

Any comments on the units of electrical sensors and blocks (see also #2488, which addresses a similar issue).

[AHaumer]

Which one of the following two possibilities should be used:
(re(unit="W"), im(unit="var"))
(redeclare SIunits.ActivePower re, redeclare Modelica.ReactivePower im)

[christiankral]

Which one of the following two possibilities should be used:
(re(unit="W"), im(unit="var"))

I guess we should go with the first possibility, as a real signal unit may be modified by unit as well.

[beutlich]

Which one of the following two possibilities should be used:
(re(unit="W"), im(unit="var"))

I guess we should go with the first possibility, as a real signal unit may be modified by unit as well.

Agreed.

[christiankral]

The units of the Analog sensors use (for example):

RealOutput y(unit = "V")

The sensors of the machines use the quantity and the final attribute:

RealOutput V(final quantity="ElectricPotential", final unit="V")

My preferences actually are:

• Only use y(unit = "V") but no quantity
• Do not use the final attribute

In this case I would also change the Modelica.Electrical.Machines.Sensors.

@beutlich Any objections?

[AHaumer]

@beutlich and @HansOlsson - could give us some hints please:
What does a tool check - quantity or unit?
What are the advantages of using quantity AND unit? Are there disavantages?
What are the disadvantages of using final?

[AHaumer]

Do we have to expect problems if the signal is fed to a block input?
We have problems in blocks, too: Consider Blocks.Sources.PTP
"Position" has unit "1".
"Velocity" has unit "1", should have "unit of Position"/s.
"Acceleration" has unit "1", should have "unit of Position"/s2.
Remember: Position could be an Angle, too.

[HansOlsson]

@beutlich and @HansOlsson - could give us some hints please:
What does a tool check - quantity or unit?

Primarily unit.

Note that when doing operations - like multiplying signals - we can only check the units.

When directly connecting we also check quantities for connected variables, in general the reasons is that there can be different quantities that don't mix - and in addition we use the quantity to check
However, this is not as reliable as quantity-names are not well-defined - and there are cases where different quantities are compatible.

What are the advantages of using quantity AND unit? Are there disavantages?
What are the disadvantages of using final?

The only minor issue I can see with using final for unit is that there might be an existing identical modifier, but that seems really minor.

[HansOlsson]

Do we have to expect problems if the signal is fed to a block input?
We have problems in blocks, too: Consider Blocks.Sources.PTP
"Position" has unit "1".
"Velocity" has unit "1", should have "unit of Position"/s.
"Acceleration" has unit "1", should have "unit of Position"/s2.
Remember: Position could be an Angle, too.

To me the solution is to not specify unit in these cases, i.e. remove unit="1".
A tool can then automatically deduce all of the above.

[christiankral]

To me this sounds like that

RealOutput y(final unit = "V")

is be solution to go:

• As quantity is not standardized, the is no strict need for it
• The final attribute gives the sensor models a stricter physical behavior which is OK
• In case that a user model already uses a modification of the output signal we could run into a conflict but the risk seems to be really minor

Are there objections?

[beutlich]

OK for me, except that removing the final breaks backwards-compatibility. Thus, I propose to not remove the final qualifier from signals where it is currently set.

[christiankral]

So for compatibility reasons you prefer to keep final quantity="ElectricPotential". That's OK.

[beutlich]

Yes, keep it where it alreadyis set. But do not add new quantityattributes or new final qualifiers.

[christiankral]

So use RealOutput y(unit = "V") instead of RealOutput y(final unit = "V") for all new output units?

[beutlich]

Actually, I have no strong opinion. Previously, in https://github.com/modelica/ModelicaStandardLibrary/pull/2197/files#diff-42a3cb78f53b2034a06e53baf19cae1a I added the final qualifier only for signals where it is not in SI unit, e.g., for degC or bar.

[christiankral]

OK, I will then go for RealOutput y(final unit = "V") for all new SI unit outputs and omit the final for non SI unit outputs (such as angles).

[beutlich]

Which is exactly the other way round as I did previously. 😕

[christiankral]

Hmmm... But why are non SI units final in your proposal, and the SI units are not final. Can you explain your arguments?

[beutlich]

My thought was that signals are always in SI units. For that reason you can change the unit afterwards (i.e., non final). On the other side, that signal that are uses as non-SI unit in calculations must not be changed in unit (i.e., final). Not sure if this is right at all.

[christiankral]

I am now a little undecided on how to proceed...

@HansOlsson How would you do it?

[HansOlsson]

I am now a little undecided on how to proceed...
@HansOlsson How would you do it?

As far as I understand changing the unit in this declaration doesn't change the sensor value - and thus I don't see the benefit of allowing changes (even if non-SI), and would thus always make the unit final.

If we add some complex logic to allowing switching unit - and compute values in that unit, then that unit-expression will be complicated - but still final.

[christiankral]

@HansOlsson Right, changing the unit does not change the sensor value. Your suggestion sounds reasonable to me and making every output quantity final is close to the physical nature of a sensor: The output of a voltage sensor is a voltage (in the SI unit Volt) and nothing but that.

So I suggest to go for this proposal and make every SI unit final and omit the quantity. I actually do not see any sensors which have non SI units, except the temperature sensors (and the temperature conversion blocks) of Modelica.Thermal.HeatTransfer. Everything else is a matter of displayUnit which will not be set.