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"

• 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"!?

1. OMEdit does not propose alternative units for V_nom, just "V" -- "kV" would be nice.
2. 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"?
3. 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