OMEdit: Can't change AC1ph_DC ACvoltage source fType_par parameter in the dialog

[Sup3rGeo]

Hi,

When I try to use the source ACvoltage from the AC1ph_DC blocks, I never get to set the fType_par to false (the dialog shows it grayed, read-only) regardless of the setting of fType_sys and scType_par parameters (that can be changed).

Therefore I can't get to use an ACvoltage with variable frequency in my models.

Thank you.

[Rüdiger Franke]

That's a good point. ftype_par is declared with annotation(Evaluate=true, Dialog(enable=not fType_sys)). It appears that OMEdit does not evaluate the actual value of fType_sys when rendering the parameter dialog. Dialog(enable ...) is not specific to the PowerSystems library, but commonly used in many Modelica models.

In case you are interested in a "rocky horror picture show", you might open PowerSystems.Examples.Spot.Introduction.Frequency in OMEdit and see:

• My 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). My Linux version (v1.10.0-dev.134+gb85235d) does it right.
• OMEdit shows all conditional signal inputs of voltage1 and voltage2 even if they are disabled!?
• double click on voltage1 to open the parameter dialog -- my Windows version of OMEdit will destroy the diagram layout -- my Linux version keeps the position of the icon in the diagram
• 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"!?
• OMEdit does not propose alternative units for V_nom, just "V" -- "kV" would be nice.
• 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"?
• 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.

Unit issues have been reported in another ticket (#3951).

[Francesco Casella]

When I try to use the source ACvoltage from the AC1ph_DC blocks, I never get to set the fType_par to false (the dialog shows it grayed, read-only) regardless of the setting of fType_sys and scType_par parameters (that can be changed).

This is probably related to #2661

[Rüdiger Franke]

The situation has become worse with the current master versions of OpenModelica and PowerSystems.

The following message shows up multiple times when browsing the PowerSytems library:

Scripting Notification
Stack overflow detected and was not caught.
Send us a bug report at https://trac.openmodelica.org/OpenModelica/newticket
    Include the following trace:
[bt] Execution path:
Stack overflow detected a

The two Booleans fType_par and fType_sys have meanwhile been replaced with the enumeration parameter PowerSystems.Types.SourceFrequency fType:

  type SourceFrequency = enumeration(
      Parameter "Parameter f",
      Signal "Signal omega_in",
      System "System defined") "Options for specification of frequency";

The new parameter fType does not show up in the Dialog at all. Moreover OMEdit raises:

Scripting Error
Unable to find component voltage2.omega_in while parsing connection {theta_dq0.y,voltage2.omega_in, ""}.

The connection is not drawn. See PowerSystems.Examples.Spot.Introduction.Frequency.

[Rüdiger Franke]

The crash / stack overflow was caused by an unnecessary import statement. It is fixed with ​https://github.com/modelica/PowerSystems/commit/92edf4af6ac185cc6af63d95fd4b4e54ebe5cb3c

The problems listed in comment:2 remain -- in particular the units chaos, besides evaluation of annotations.

[Francesco Casella]

The original problem reported here should be fixed (with a workaround) after comment:2:ticket:2661. Other issues (e.g. those reported in #3951) should have been fixed as well.

@rfranke, could you assess what is still wrong and report here?

[Francesco Casella]

These issues should be fixed in 1.14.0

[Francesco Casella]

The original issue is already reported in #2661, so this ticket is a duplicate of that from this point of view. This should be fixed in 1.14.0.

Other issues should have been fixed in the meantime.