Issues with OMEdit and components from the PowerSystems library

[Francesco Casella]

Open PowerSystems.Examples.Spot.Introduction.Frequency in OMEdit and see:

1. The Windows version of OMEdit (v1.10.0-dev-159-g4de9151) will hide the + and - navigation elements in the tree view of the Libraries pane on mouseover (just not nice, but see below). The Linux version (v1.10.0-dev.134+gb85235d) does it right.
2. OMEdit shows all conditional signal inputs of voltage1 and voltage2 even if they are disabled (see #2081)
3. double click on voltage1 to open the parameter dialog -- the Windows version of OMEdit will destroy the diagram layout -- the Linux version keeps the position of the icon in the diagram
4. OMEdit shows the Scripting Error "error parsing unit VA"
5. The voltage veff is in p.u., which is represented with "V/V", relative to V_nom, in the PowerSystems library. OMEdit proposes the alternative units "rad" and "sr"!?
6. OMEdit does not propose alternative units for V_nom, just "V" -- "kV" would be nice.
7. The angle alpha0 is shown with the SI unit "rad". OMEdit proposes to alternatively use "sr". Why doesn't OMEdit use or even propose the displayUnit "deg"?
8. OMEdit proposes for the frequency f the alternative unit "Bq". f is bound to the parameter system.f. What is the meaning of changing the display unit of a variable name?

Once you got around all these things, you finally find out that fType_par is always disabled, independent of the actual value of fType_sys. It appears that OMEdit generally lacks the evaluation of parameters when rendering graphics or parameter dialogs, see #2661 and #4008.

Originally reported by @rfranke as a comment in #4008.

[Lennart Ochel]

I think we should not try to provide all possible alternatives for all available units. It is good to provide the most frequently used alternatives and an option to define custom display units which can be added by the user. The conversion can be handled using the functionality of the current unit checking module, which is already available.

[Rüdiger Franke]

I agree that an explicit list of conversions would be better than a magic algorithm. Ideally it should be possible to adjust the list to application / regional needs. People working on electrical circuits might want to see mV; people working on power electronics kV instead. Simularily some people might prefer Imperial units, while others prefer SI. Which automatic algorithm could know that?

[Francesco Casella]

I guess this stuff has deliberately been left out of the Modelica specification, because the expected behaviour should be user-specified and orthogonal to the Modelica library code, as the case of US customers who want to see Imperial units makes clear.

One possible option: have OMEdit use user-specific configuration files with preferred units for specific libraries.

[Rüdiger Franke]

A definition per library would of course be best. It can also become cumbersome though if one has to repeat the same definitions for multiple library (e.g. for Modelica.Fluid and for ThermoPower). This is why I think that a global definition is needed at a first glance.

[Lennart Ochel]

@Adeel Do you have all the information available in OMEdit? Or is some kind of new API needed that calculates the scaling between units?

[Francesco Casella]

Replying to rfranke:

A definition per library would of course be best. It can also become cumbersome though if one has to repeat the same definitions for multiple library (e.g. for Modelica.Fluid and for ThermoPower). This is why I think that a global definition is needed at a first glance.

Of course you could have both global definitions and library-specific definitions overriding some of them.

[Adeel Asghar]

Replying to lochel:

@Adeel Do you have all the information available in OMEdit? Or is some kind of new API needed that calculates the scaling between units?

The API is already there to calculate scaling i.e., convertUnits ​https://build.openmodelica.org/Documentation/OpenModelica.Scripting.convertUnits.html

[Adeel Asghar]

1. This is a problem in Qt 5.6.0 (​https://bugreports.qt.io/browse/QTBUG-52689) which is currently the version we are using for Windows. The problem is already solved in newer versions of Qt so we need to updated our msys Qt version.

3. I can't reproduce this with OMEdit v1.11.0-dev-137-gf063a54.

6. This is fixed in 0cba003/OMCompiler and f063a54/OMEdit.

[Rüdiger Franke]

7. 0901cc3/OMCompiler adds the unit deg, the display unit for Modelica.SIunits.Angle.

Overall the OpenModelica unit system appears too radical when reducing everything just to base units. This is why it mixes up for instance Bq with Hz.

I tried to also add the unit rpm for rotations per minute:

  addDerived("angular velocity", "revolutions per minute", "rpm", "rad/s", Rational(0), Rational(3141592653589793, 30000000000000000), Rational(0), true);

OpenModelica would just treat it as further alternative to Bq!?

The OMEdit selection dialog should only combine units if they have the same quantityName -- the first argument to addDerived. We have:

• Bq: activity referred to a radionuclide
• Hz: frequency
• rpm: angular velocity

How can this be achieved?

[Rüdiger Franke]

The consideration of the quantity does neither help, because for instance VA, var and W all have quantitiy Power in Modelica.SIunits, but should not be mixed up.

For the upcoming OpenModelica 1.10 release, OMEdit pull request 33 restricts the list of unit options to the declared displayUnit and the internal unit of a variable. This is already quite useful, because many Modelica libraries declare own units and displayUnits and people might want to switch to the internal unit of a parameter.

For more choices we would indeed need a separate configuration file that groups units belonging together. This file could then also be localized and should even override the declared displayUnit -- e.g. to display temperatures in degF instead of degC per default.

[Rüdiger Franke]

OMCompiler pull request 1116 removes units that are converted automatically, like MW. This in particular makes sense along with OMEdit pull request 33 that does not invoke getDerivedUnits anymore because the result is unsatisfactory (e.g. mixes Hz with Bq and rad with sr).

Moreover the pull request adds missing units (units used by MSL and important Imperial units, like inch, psi and mph).

[Adeel Asghar]

With recent commits from Rudiger and me the situation is quite better now.
I believe only point 6 is the one that is still not done. I have no idea how we want to achieve that. Perhaps we can discuss it in a new ticket.
Also we can follow condition signals issue in #2081 and parameter enable/disable issue in #2661 and #4008.

[Rüdiger Franke]

Regarding point 6 it is hard to know for a tool, which display units are wanted, also considering that this changes per library ... e.g. between micro electronics and power electronics. This is why the PowerSystems library defines displayUnit kV for voltages itself meanwhile. This propagates to OMEdit.

[Martin Sjölund]

1.11 will be released before 2.0