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 Windows version of OMEdit crashes when browsing the PowerSystems library. The Linux version shows the following corruted message multiple times:

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.