Coder Social home page Coder Social logo

modelica-3rdparty / powersystems Goto Github PK

View Code? Open in Web Editor NEW
60.0 30.0 35.0 2.1 MB

Free (standard conform) library that is intended to model electrical power systems at different levels of detail both in transient and steady-state mode.

Modelica 98.46% Motoko 1.54%
modelica modelica-library standard-conforming

powersystems's Introduction

PowerSystems

The library is intended to model electrical power systems at different levels of detail both in transient and steady-state mode.

Library description

PowerSystems provides a framework and examples for the flexible modeling of electical power systems. Generic component models adapt to different application needs by using a replaceable PhaseSystem. Moreover the library contains the extensive sets of detailed one phase and transient three phase component models of the former SPOT library.

In particular this shall cover systems like:

  • AC power systems, including dc power flow, steady-state, transient, and unsymmetric,
  • Variable frequency systems, e.g. in wind turbines or for drive control, and
  • DC power systems, like HVDC

See also the publication Franke, Wiesmann: Flexible modeling of electrical power systems - the Modelica PowerSystems library, Modelica conference 2014.

Current release

Download PowerSystems v2.0.0 (2024-05-07)

Revisions

  • Version v2.0.0 (2024-05-07)

    • Upgrade used Modelica Standard Library to version 4.0.0 (#50, #51)
  • Version v1.0.1 (2021-06-30)

    • Remove StateSelect.prefer from angular velocity of electrical machines
    • Make semiconductor model in Semiconductors.PhaseModules.SwitchModule replaceable.
    • Fix unit in AC3ph.Impedances.Inductor (#43).
    • Added missing 'each' to AC3ph.Machines.Synchron_pm_ctrl (#44).
    • Small clean-ups
  • Version v1.0.0 (2018-11-12)

    • Added missing 'each'.
    • Enhance sensors with scaling of output signals.
    • Add steady-state AC3ph PQload.
  • Version v0.6.0 (2017-01-18)

    • Enhance AC3ph with replaceable PhaseSystem. Many components work with ThreePhase_dq as well, besides the default ThreePhase_dq0.
    • Introduce own SI sub-package to get appropriate display units.
    • Treat PerCent as display unit, 0..1 internally.
    • Implement inertial reference frame for Generic components (#18).
    • Fix some HTML warnings (#20).
    • Fix measurement units in PWM control models (#21).
    • Make phasor of PVImeter unconditional (#26).
    • Unify naming of start values for Loads.
    • Reorganize Examples to better outline the Introductory examples and to better reflect the three component sub-packages AC3ph, AC1ph_DC and Generic.
  • Version v0.5.0 (2016-09-20)

    This release introduces a couple of changes that improve the modeling experience and unify the library with other Modelica libraries.

    • Introduce replaceable model and record types, instead of replaceable model and record instances.
    • Simplify initialization
      • Introduce enumeration Types.Dynamics dynType, replacing Booleans stIni_en, steadyIni_t and transientSim
      • Unify naming of start parameters from *_ini to *_start
      • Simplify initialization of machine rotors and line models
    • Rework AC3ph and AC1ph_DC line models: rename PIline to Tline and introduce new PIline.
    • Rework tap changers of AC3ph and AC1ph_DC trafo models: treat effect of tap changers in replaceable Topology, enabling more arrangements such as phase angle regulating.
    • Add examples for electrical drive trains of wind turbines
    • Reorganize Basic package to Utilities.
    • Add Inline=true annotations to functions that shall be inlined.
    • Introduce PhaseSystem Voltage and Current types, including nominal values of 1000.
    • Upgrade Phasor model to standard Modelica graphics.
    • Base on Modelica 3.2.2 instead of 3.2.1 (without changing anything).
  • Version v0.4.0 (2015-03-14)

    • fix Generic components to work with simple ThreePhase_d again (was broken in v0.3)
    • rework parameter records (move parameter qualifiers from record members to whole records to permit their construction with functions)
    • remove ambiguous start values
    • lot of clean-up
  • Version v0.3 (2014-10-20)

    • add initial equations to Generic models and related examples
    • add start parameters to AC1phDC and extend transient initialization
    • add start parameters to AC3ph to improve steady-state initialization
    • fix use of condionally declared variables
    • clean up annotations
    • rename dqo to dq0
  • Version v0.2.1 (2014-08-15)

    • replace deprecated classDirectory() with loadResource()
    • fix references to Connections package
  • Version v0.2 (2013-04-18)

    • Clean-up Examples and Resources
  • Version v0.1.3 (2013-02-28)

    • Generic: change connector units from MW to W
  • Version v0.1.2 (2012-12-22)

    • Rework Basic.Types to using SI units
    • Adapt parameter records to SI units
  • Version v0.1.1 (2012-12-15)

    • Rename Utilities package to Basic
    • Remove BasePU and BaseSI sub-packages
  • Version v0.1 (2012-12-06)

    • Initial version

License

Copyright © 2007-2015, Modelica Association.

This Modelica package is free software and the use is completely at your own risk; it can be redistributed and/or modified under the terms of the Modelica License 2.

Development and contribution

Contributors:

  • Hansjürg Wiesmann († 2015): Wrote the original SPOT library and supported the creation of the PowerSystems library.
  • Martin Otter: Converted the original Spot library from Modelica 2 to Modelica 3.
  • Rüdiger Franke: Created the PowerSystems library out of the PowerFlow concept library and the SPOT library.

You may report any issues with using the Issues button.

Contributions in shape of Pull Requests are always welcome.

Acknowledgement

This work was in parts supported by the ITEA2 MODRIO project by funding of BMBF under contract number ITEA 2 - 11004. Work on the predecessor PowerFlow library was in parts supported by the ITEA2 EUROSYSLIB project by funding of BMBF under contract number ITEA 2 - 06020. Work on the predecessor Spot library was in parts supported by the RealSim project by funding of the IST Programme, Contract No. IST-1999-11979.

powersystems's People

Contributors

adrpo avatar beutlich avatar casella avatar dietmarw avatar gallleo avatar rfranke avatar sjoelund avatar tbeu avatar thorade avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

powersystems's Issues

SimulationX errors

When opening the library in SimulationX Professional 3.6.2.27707 and running the Power Worl Example and endless list of errors
sim
appear.

Division by zero in PowerSystems.Examples.AC3ph.Generation.Islanding

The Islanding example:

PowerSystems.AC3ph.Generation.TurboPMgenerator turboGen(
redeclare model Governor = PowerSystems.Control.Governors.Governor1st
"1st order",
redeclare model Generator = PowerSystems.AC3ph.Machines.Synchron_pm (
redeclare record Data =
PowerSystems.Examples.Data.Machines.Synchron_pm560V_100kVA)
"nth order")

has a division by zero problem.

Through a series of extends, we end up in PowerSystems.AC3ph.Machines.Partials.SynchronBase, specifically this line:

v_f = v_rd[1]/c.wf;

In this context, c.wf is 0. It is computed here:

c.wf := omega_nom*c.L_md[1]*p.If_nom/p.V_nom;

In this context, p is PowerSystems.Examples.Data.Machines.Synchron_pm560V_100kVA, which has:

Erroneous initial equation when using PIline in power Transfer example

I want to produce a more realistic "PowerTransfer" example in which I use realistic line parameters (the built-in OHline_132kV are unrealistic since give rise to a totally unrealistic characteristic impedance of 7.7 ohm). I want also to compare the RX line behaviour with a PI line.
Once done, I will publish here example ans thorough documentation for possible inclusion in the library.

However I came across into a nasty issue.
Consider to make a slight modification to Examples.AC3ph.Transmission.PowerTransfer, consisting in substituting the line model from RXline to PIline, and line parameters into OHline_132kV.

The model checks fine.
When run (in Dymola), however, the model produces the following error message:

The initialization problem is overspecified for variables of element type Real.
The initial equation 
0.0 = 0.0;
refers to variables, which all are known.
To correct it you can remove this equation
The initial equation 
0.0 = 0.0;
refers to variables, which all are known.
To correct it you can remove this equation
The initial equation 
0.0 = 0.0;
refers to variables, which all are known.
To correct it you can remove this equation
The initial equation 
0.0 = 0.0;
refers to variables, which all are known.
To correct it you can remove this equation

It seems to be more a bug than an initial condition related issue.
I will try to solve it , but I prefer to share it with GitHub, just in case someone is interested.

Voltage source not respecting parameter frequency ?

I tried to use 2 voltage sources of same amplitude but set at different frequencies (50 and 51 Hz) to oscillate power across a connecting impedance at the beat frequency. Voltage sources I used were from AC3ph.Sources.Voltage. However both voltages calculated identically across time (therefore no current between them). Digging into the code, the Voltage source did not use the calculated theta from the frequency (fType = parameter).

The line in question in Sources.mo for model Voltage is

phi = term.theta[1] + alpha + system.alpha0;
term.v = PS.map({V*cos(phi), V*sin(phi), sqrt(3)*neutral.v});

However, term.theta[1] appears always set to system.thetaRel (set in partial SourceBase). Whilst theta for the Voltage instance is calculated correctly (in partial VoltageBase), it seems as if it is never used.

My model worked when I changed the library line to:

phi = (theta - system.thetaRef) + alpha + system.alpha0;

that is, calculating the angle of the voltage source instance relative to the reference frame.

Fixing it here does not seem right though - term.theta should be changed?? However, line elements connect theta through (term_p.theta = term_n.theta) so you would end up with an over-defined system or one that cannot be solved.

As it stands, term.theta seems a bit useless as it can only be = {system.thetaRel, system.thetaRef}. Or am I missing something? It would seem to me more intuitive if each active element's term.theta referred to its actual relative angle to the reference frame and passive elements did not pass it through. In any regard, the Voltage source appears to have a fixable bug as it currently does not respect the frequency parameter.

I am pretty new to this so sorry if I have missed something fundamental or some setting somewhere.

Modelica Standard Library 4.0.0

The PowerSystems library still uses Modelica Standard Library (MSL) version 3.2.3. It would be great to have it updated to MSL v. 4.0.0.

Ac1ph_DC inductor allows unphysical parameters

Consider AC1ph_DC.Impedances.Inductor.
The inductor reactance is entered as a 2x2 matrix, containing [xs[1],xm; xm,xs[2]]
This matrix is directly accessible through the parameter dialog box. This implies that the user can use a matrix having the four values all different from each-other, which, AFAIK, is unrealistic, since the matrix should be symmetric.
I propose the change the code into the following one:

model Inductor "Inductor with series resistor, 1-phase"
  extends Partials.ImpedBase;

  parameter Types.Generic.Resistance[2] r={0,0} "resistance";
  parameter Types.Generic.Reactance[2] xs={1,1} "self reactances";
  parameter Types.Generic.Reactance xm=0 
    "mutual reactance between conds 1 and 2";
protected 
  final parameter Real[2] RL_base=Utilities.Precalculation.baseRL(
      puUnits,
      V_nom,
      S_nom,
      2*pi*f_nom);
  final parameter SI.Resistance[2] R=r*RL_base[1];
  //  final parameter SI.Inductance[2, 2] L=x*RL_base[2];
  final parameter SI.Inductance[2, 2] L=[xs[1], xm; xm, xs[2]]*RL_base[2];

initial equation 
  if dynType == Types.Dynamics.SteadyInitial then
    der(i) = zeros(2);
  elseif dynType == Types.Dynamics.FixedInitial then
    i = i_start;
  end if;

equation 
  L*der(i) + diagonal(R)*i = v;
end Inductor;

EPS: a lab for Power Systems Library

I contribute to Power System Library with tickets.
But I want to do more.

Therefore I've changed it whenever I deemed useful, and uploaded the modified copy into gitHub.
It is available at:
https://github.com/ceraolo/Electric-Power-Systems-EPS

Note that some explanation of how Power Systems Library works (that I miss in the embedded documentation); and on the modifications that I propose to issues I see, is reported in file added in the root of the library: "Basic explanation.docx". this file will be continuously updated.

In my idea EPS should work as a laboratory for experimenting improvements on the Power Systems Library. I hope that whatever change proposed in EPS is deemed useful and acceptable by the people that maintain PSL, will be incorporated there. Also whatever part of Basic explanation.docx is deemed of interest may be freely added to PSL.

Suggestions and comments are welcome directly on the EPS GitHub area.

Remove or updated `distclean.py`

Currently the repository contains distclean.py which is really superfluous given that the same can be achieved by simply running git clean -fdx. If you really want to keep the file it should be

a. updated for git (currently only .hg dirs are hardcoded)
b. placed under Resources/Scripts as the Modelica package root should not contain non-Modelica files.

On which Modelica tool has this library be written

Hi,
I am interested on your work and trying to fully understand the library. But I cant run some examples (most importantly the Wind one). Both OpenModelicaEditor and SystemModeler gets out errors. I would like to know the tool you used to develop this library.
Thank you in advance,
Petros

how do I open this package under modellica?

Hi, I am an absolutely new to this software, and wanted to give it a try. I am wondering if someone can tell me how to open, or get started with this package. I have openmodellica installed in my OS.

spurious % on %name string

In several models (e.g. Examples.PowerWorld.Components.HydroPlant) the name I read for the model name textString="%name%", while it should be textString="%name", instead (see. Modelica spec 3.4 sect. 18.6.5.5).
Note that this mistake does not cause visualization errors in Dymola, while causes an erroneous "% to be shown in OpenModelica.

Again on line parameters (compare #31)

This is a companion ticket of #31. that one referred to data present in Examples.Data.Lines, this one refers to the two lines in AC3ph.Lines.Parameter.RXline.
Here there is an evident mistake in V_nom: 1 V is totally unrealistic.
But how to correct the mistake? A typical HV line has a characteristic impedance that ranges between 200 and 450 ohm. We can reverse-engineer the data to find the characteristic impedance in case of two values.
Under the hypothesis that resistance and reactance values are correct (and only V_nom is wrong), we compute Zc=sqrt(X/B)=sqrt(1/0.025)=6.325 p.u.

  1. V_nom=66 kV => Znom=66^2/100=43.56 ohm => Zc=276.086 ohm
  2. V_nom=132 kV => Zc=132^2/100=174.24 => Zc=1102.068 ohm.
    Both voltage levels IEC standard (60038)

So, to conclude:

  1. data in Examples.Data.Lines should be given along with the associated geometry, as I did in a first case (#31)
  2. data in AC3ph.Lines.Parameter.RXline may be just "generic realistic examples with round numbers. In this case, the values already present for reactances and susceptances are ok. V_Nome should be set to 66 kV.
  3. the power transfer example, that is linked to AC3ph.Lines.Parameter.RXline data should be modified so that the voltage at the two ends is 66 kV.

If this is done, I could supply a description of PowerTransfer, with plots and phasors, that shows nice compliance of the results with theory.

Division by zero in average Rectifier

Model Examples.Spot.AC3phRectifier is a good example where a diode rectifier feeds a constant source.

A twin example in the Power Systems Library feeding a zLoadDC would be useful to have a more complete idea on the rectifier behaviour.
A first attempt I made with Rectifier was unsuccessful, so I tried with RectifierAverage.
The model I made is attached here. It causes a division by zero:
Model error - division by zero: (1.0) / (sqrt(rectifier.iAC2)) = (1) / (0)
Maybe the culprit is the RectifierAverage equation:
switch_dq0 = S_abs*AC.i/(sqrt(iAC2) + 1e-5);
but this should not cause division by zero.
I will continue to dig into this issue, and in case find a solution will publish here.
However I deemed useful to to share this experience with others as well.

The model is:

model RectifierAvToRL "Rectifier"

  inner PowerSystems.Utilities.System system(dynType=PowerSystems.Types.Dynamics.FixedInitial,
      refType=PowerSystems.Types.ReferenceFrame.Inertial)
    annotation (Placement(transformation(extent={{-40,40},{-20,60}})));
  PowerSystems.Blocks.Signals.TransientPhasor transPh(
    t_change=0.1,
    t_duration=0.1,
    a_start=2,
    a_end=1) annotation (Placement(transformation(extent={{-100,20},{-80,40}})));
  PowerSystems.AC3ph.Sources.Voltage vAC(use_vPhasor_in=true, V_nom=100)
    annotation (Placement(transformation(extent={{-80,0},{-60,20}})));
  PowerSystems.AC3ph.Impedances.Inductor ind(
    r=0.05,
    V_nom=100,
    S_nom=1e3) annotation (Placement(transformation(extent={{-50,0},{-30,20}})));
  PowerSystems.AC3ph.Sensors.PVImeter meterAC(
    abc=true,
    av=true,
    V_nom=100,
    S_nom=1e3,
    phasor=true,
    puUnits=false,
    tcst=0.01) annotation (Placement(transformation(extent={{-20,0},{0,20}})));

  PowerSystems.AC1ph_DC.Sensors.PVImeter meterDC(
    av=true,
    V_nom=100,
    S_nom=1e3,
    puUnits=false,
    tcst=0.01) annotation (Placement(transformation(extent={{38,0},{58,20}})));
  PowerSystems.AC3ph.Nodes.GroundOne grd1
    annotation (Placement(transformation(extent={{-80,0},{-100,20}})));

  PowerSystems.AC1ph_DC.Loads.ZloadDC zLoadDC(puUnits=false, p0=1000)
    annotation (Placement(transformation(extent={{72,0},{92,20}})));
  PowerSystems.AC3ph.Inverters.RectifierAverage rectifier
    annotation (Placement(transformation(extent={{28,0},{8,20}})));
  PowerSystems.Common.Thermal.BdCondV bdCond
    annotation (Placement(transformation(extent={{8,26},{28,46}})));
equation 
  connect(vAC.term, ind.term_p)
    annotation (Line(points={{-60,10},{-50,10}}, color={0,110,110}));
  connect(ind.term_n, meterAC.term_p)
    annotation (Line(points={{-30,10},{-20,10}}, color={0,110,110}));
  connect(transPh.y, vAC.vPhasor_in)
    annotation (Line(points={{-80,30},{-64,30},{-64,20}}, color={0,0,127}));
  connect(grd1.term, vAC.neutral)
    annotation (Line(points={{-80,10},{-80,10}}, color={0,0,255}));
  connect(meterDC.term_n, zLoadDC.term)
    annotation (Line(points={{58,10},{72,10}}, color={0,0,255}));
  connect(meterAC.term_n, rectifier.AC)
    annotation (Line(points={{0,10},{8,10}}, color={0,120,120}));
  connect(meterDC.term_p, rectifier.DC)
    annotation (Line(points={{38,10},{28,10}}, color={0,0,255}));
  connect(rectifier.heat, bdCond.heat)
    annotation (Line(points={{18,20},{18,20},{18,26}}, color={176,0,0}));
  annotation (
    Documentation(info="<html>
<p>This is a system showing the behaviour of diode rectifier component.</p>
<p>The source AC voltage is reduced during the simulation starting at around 80 ms. The DC current and AC and DC powers behave correspondingly. </p>
<p><a href=\"modelica://PowerSystems.Examples.Spot.InvertersAC3ph\">up users guide</a> </p>
</html>"),
    experiment(
      StopTime=0.2,
      Interval=0.2e-3,
      Tolerance=1e-005),
    Diagram(coordinateSystem(extent={{-100,-20},{100,60}})),
    Icon(coordinateSystem(extent={{-100,-20},{100,60}})),
    uses(PowerSystems(version="0.5.0")));
end RectifierAvToRL;

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

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.

problem running example model of DFIG

Hi all, I am totally new to the openmodelica and this powerSystem lib. When I tries to run the DFIG example, I have error as:

%%---------------------------------------------

[4] 14:55:35 Translation Error
Internal error IndexReduction.pantelidesIndexReduction failed! System is structurally singular and cannot be handled because the number of unassigned equations is larger than the number of states. Use -d=bltdump to get more information.

[5] 14:55:35 Translation Error
No system for the symbolic initialization was generated

[6] 14:55:43 Scripting Notification
PowerSystems requested package Modelica of version 3.2.2. Modelica 3.2.3 is used instead which states that it is fully compatible without conversion script needed.

[7] 14:55:43 Translation Error
[PowerSystems.AC3ph.Machines: 2208:3-2208:47]: Could not evaluate structural parameter (or constant): n_r which gives dimensions of array: L_r[n_r]. Array dimensions must be known at compile time.

[8] 14:55:43 Translation Error
Error occurred while flattening model PowerSystems.Examples.Wind.WindTurbine_DFIG

%%---------------------------------------------

do you have any suggestion to fix the problem?

Please update modelica/PowerSystems to 1.0.0

The default link for the Power System library still points to the 0.6.0 release. Please update it to 1.0.0, so that people and the OpenModelica Hudson CI use the latest released version instead of the old one.

When done, please close #5242 on the OpenModelica trac.

Example simulation error

Error occurs when i simulate 'PowerSystems/Examples/GenerationAC3ph/Turbin generator' example file.

Error message is as follows:

division by zero at time 0, (a=45160) / (b=0), where divisor b expression is: generator.c.omega_nom

Debug more

simulation terminated by an assertion at initialization

Process crashed.

Simulation process failed. Exited with code -1.

Version of modelica is 'OpenModelica-v1.9.4-dev.beta1-85'
What's the problem?

Thank you for reading.

Doc links

Many of the documentation links of the HTML doc miss the modelica:// uri prefix.

initialization problem of wind DFIG example

Hello, I am a beginner in Modelica. When I ran the wind DFIG example, the software reported an error:
The initialization problem is inconsistent due to the following equation: 0 != 1.22474 = 1.224744871391589 * cos(select2.alpha0) * select2.v0 - inverter2.switch_dq0[1]
I am using the latest version of OpenModelica

Inverter carrier frequency should be a GUI parameter

Consider AC3ph.Inverters.Inverter and AC3ph.Inverters.InverterAverage. Strangely f_carrer can be chosen from InverterAverage GUI, while to change it for inverter the user should open the inverter model and manually change the modulator f_carr.
The same is true for single-phase inverters.

I thing that

  1. f_carr should be exposed in non-averaged inverters GUIs, since it determines the very shape of voltages and currents,
  2. I'm not sure what's the usage of f_carr in Inverter Average. This piece of info should be added in the information of averaged inverter models, in case it is really needed, or be dropped in case it (and hsw_nom) is redundant.

Please release 0.6.1 with latest fixes

@rfranke I am monitoring the status of PowerSystems with the new OMC front end. There are many failures due to missing 'each' that were corrected in the master version with some PRs, but unless you make a 0.6.1 (or 0.7.0) release, Hudson won't take them into consideration, because it runs on the last released version.

Thanks!

PVIMeter improvement proposal(s)

In PVImeter, it the user chooses "phasor=true" v_norm, i_norm, alpha_v, alpha_i are computed and can be plotted.
Is phasor=false v_norm and i_norm are not computed, but alpha_v and alpha_i are computed and set to zero.
The following code makes a correction in such a way that also alpha_v and alpha_i are not computed (and not available for plotting) when they have no meaning, i.e. when phasor=false. Moreover, the info text is enhanced.

model PVImeter "Power-voltage-current meter, 3-phase dq0"
  extends Partials.Meter2Base;

  parameter Boolean av=false "time average power"
    annotation (Evaluate=true, Dialog(group="Options"));
  parameter SI.Time tcst(min=1e-9) = 1 "average time-constant"
    annotation (Evaluate=true, Dialog(group="Options", enable=av));

  function v2vpp_abc
    input SIpu.Voltage[3] v_abc;
    output SIpu.Voltage[3] vpp_abc;
  algorithm 
    vpp_abc := {v_abc[2],v_abc[3],v_abc[1]} - {v_abc[3],v_abc[1],v_abc[2]};
  end v2vpp_abc;

  output SIpu.Power[3] p(each stateSelect=StateSelect.never);
  output SIpu.Power[3] p_av=pav if av;
  output SIpu.Voltage[3] v(each stateSelect=StateSelect.never);
  output SIpu.Voltage[2] vpp(each stateSelect=StateSelect.never);
  output SIpu.Current[3] i(each stateSelect=StateSelect.never);

  output SIpu.Voltage[3] v_abc(each stateSelect=StateSelect.never)=
    transpose(Park)*v if abc;
  output SIpu.Voltage[3] vpp_abc(each stateSelect=StateSelect.never)=
    v2vpp_abc(transpose(Park)*v) if abc;
  output SIpu.Current[3] i_abc(each stateSelect=StateSelect.never)=
    transpose(Park)*i if abc;

  output SIpu.Voltage v_norm(stateSelect=StateSelect.never) = sqrt(v*v) if 
    phasor;
  output SI.Angle alpha_v(stateSelect=StateSelect.never)=atan2(Rot_dq[:, 2]*v[1:2],
     Rot_dq[:, 1]*v[1:2]) if phasor;
  output SIpu.Current i_norm(stateSelect=StateSelect.never) = sqrt(i*i) if 
    phasor;
  output SI.Angle alpha_i(stateSelect=StateSelect.never)=atan2(Rot_dq[:, 2]*i[1:2],
                    Rot_dq[:, 1]*i[1:2]) if phasor;
  output Real cos_phi(stateSelect=StateSelect.never) = cos(alpha_v - alpha_i) if 
       phasor;
protected 
  outer Utilities.System system;
  final parameter PS.Voltage V_base=Utilities.Precalculation.baseV(puUnits,
      V_nom);
  final parameter PS.Current I_base=Utilities.Precalculation.baseI(
        puUnits,
        V_nom,
        S_nom);
  SIpu.Power[3] pav;

initial equation 
  if av then
    pav = p;
  end if;

equation 
  v = term_p.v/V_base;
  vpp = sqrt(3)*{v[2],-v[1]};
  i = term_p.i/I_base;
  p = {v[1:2]*i[1:2],-j_dq0(v[1:2])*i[1:2],v[3]*i[3]};
  if av then
    der(pav) = (p - pav)/tcst;
  else
    pav = zeros(3);
  end if;
/*  
  if phasor then
    alpha_v = atan2(Rot_dq[:, 2]*v[1:2], Rot_dq[:, 1]*v[1:2]);
    alpha_i = atan2(Rot_dq[:, 2]*i[1:2], Rot_dq[:, 1]*i[1:2]);
  else
    alpha_v = 0;
    alpha_i = 0;
    end if;
 */
  annotation (
    defaultComponentName="PVImeter1",
    Icon(coordinateSystem(
        preserveAspectRatio=false,
        extent={{-100,-100},{100,100}},
        grid={2,2}), graphics={
        Rectangle(
          extent={{-20,24},{20,20}},
          lineColor={135,135,135},
          fillColor={175,175,175},
          fillPattern=FillPattern.Solid),
        Ellipse(
          extent={{-8,8},{8,-8}},
          lineColor={135,135,135},
          fillColor={175,175,175},
          fillPattern=FillPattern.Solid),
        Line(
          points={{0,0},{20,0}},
          color={0,100,100},
          thickness=0.5),
        Line(points={{-15,50},{15,64}}, color={135,135,135}),
        Line(points={{-15,40},{15,54}}, color={135,135,135}),
        Line(points={{-15,30},{15,44}}, color={135,135,135})}),
    Documentation(info="<html>
<p>&apos;Meters&apos; are intended as diagnostic instruments. They allow displaying signals in alternative representations, either in SI-units or in &apos;pu&apos;.</p>
<p>As they use time-dependent coordinate transforms, use them only when and where needed. Otherwise use &apos;Sensors&apos;.</p>
<p>Output variables in the chosen reference system:</p>
<pre>  p         {AC active, AC reactive, DC} power term_p to term_n
  v          voltage phase-to-ground dq0
  vpp        voltage phase-to-phase dq
  i          current dq0, term_p to term_n</pre>
<p>Optional output variables:</p>
<pre>  p_av       power term_p to term_n, time tau average of p (only if av=true)
  v_abc      voltage phase-to-ground,  abc-inertial system (only if abc=true)
  vpp_abc    voltage phase-to-phase,   abc-inertial system (only if abc=true)
  i_abc      current term_p to term_n, abc-inertial system (only if abc=true)
  v_norm     norm(v) (only if phasor=true)
  i_norm     norm(i) (only if phasor=true)
  alpha_v    phase(v)(only if phasor=true)
  alpha_i    phase(i)(only if phasor=true)
  cos_phi    cos(alpha_v - alpha_i) (only if phasor=true)</pre>
<p><i>Comment on the sign-definition of reactive power see</i> ACdq0.Sensors. </p>
</html>"));
end PVImeter;

Moreover I wonder whether the following row:

  output SI.Angle alpha_v(stateSelect=StateSelect.never)=atan2(Rot_dq[:, 2]*v[1:2],
     Rot_dq[:, 1]*v[1:2]) if phasor;

can be changed into the simpler (and equally correct?):

  output SI.Angle alpha_vMod(stateSelect=StateSelect.never)=atan2(v[2], v[1]) if 
    phasor;

frequent error in PowerSystem Library

frequent error in PowerSystem Library: "Could not evaluate structural parameter (or constant): n_r which gives dimensions of array: L_r[n_r]. Array dimensions must be known at compile time."
an example in this model:

model Inverter2 "Inverter, controlled rectifier"
inner PowerSystems.System system(ref = "inertial") annotation(Placement(transformation(extent = {{-80, 60}, {-60, 80}})));
PowerSystems.AC3ph.Impedances.Inductor ind(r = 0.05) annotation(Placement(transformation(extent = {{-50, -10}, {-30, 10}})));
PowerSystems.AC3ph.Sensors.PVImeter meterAC(av = true, tcst = 0.1) annotation(Placement(transformation(extent = {{-20, -10}, {0, 10}})));
replaceable PowerSystems.AC3ph.Inverters.Inverter ac_dc(redeclare PowerSystems.Control.Modulation.PWMasyn modulator "sine PWM asyn", redeclare PowerSystems.AC3ph.Inverters.Components.InverterSwitch inverter "switch, no diode, no losses") annotation(Placement(transformation(extent = {{30, -10}, {10, 10}})));
PowerSystems.AC1ph_DC.Sensors.PVImeter meterDC(av = true, tcst = 0.1) annotation(Placement(transformation(extent = {{40, -10}, {60, 10}})));
PowerSystems.AC1ph_DC.Sources.DCvoltage vDC(pol = 0, puUnits = true, V_nom = 400, v0 = 1.2) annotation(Placement(transformation(extent = {{90, -10}, {70, 10}})));
PowerSystems.AC3ph.Nodes.GroundOne grd2 annotation(Placement(transformation(extent = {{90, -10}, {110, 10}})));
replaceable PowerSystems.AC3ph.Machines.Asynchron asynchron(par(V_nom = 400, S_nom = 1e3)) annotation(Placement(transformation(extent = {{-56, -34}, {-76, -14}})));
PowerSystems.Mechanics.Rotation.Rotor rotor annotation(Placement(transformation(extent = {{-72, -72}, {-52, -52}})));
PowerSystems.Mechanics.Rotation.Torque torq(scType_par = false, tau0 = 10) annotation(Placement(transformation(extent = {{-12, -72}, {-32, -52}})));
PowerSystems.Blocks.Signals.Transient trsSignal(t_change = 0.5, t_duration = 1, s_ini = 10, s_fin = 10) annotation(Placement(transformation(extent = {{24, -72}, {4, -52}})));
equation
connect(ind.term_n, meterAC.term_p) annotation(Line(points = {{-30, 0}, {-20, 0}}, color = {0, 110, 110}));
connect(meterAC.term_n, ac_dc.AC) annotation(Line(points = {{0, 0}, {10, 0}}, color = {0, 110, 110}));
connect(ac_dc.DC, meterDC.term_p) annotation(Line(points = {{30, 0}, {40, 0}}, color = {0, 0, 255}));
connect(meterDC.term_n, vDC.term) annotation(Line(points = {{60, 0}, {70, 0}}, color = {0, 0, 255}));
connect(vDC.neutral, grd2.term) annotation(Line(points = {{90, 0}, {90, 0}}, color = {0, 0, 255}));
connect(ind.term_p, asynchron.term) annotation(Line(points = {{-50, 0}, {-50, -24}, {-56, -24}}, color = {0, 120, 120}, smooth = Smooth.None));
connect(asynchron.airgap, rotor.flange_p) annotation(Line(points = {{-66, -18}, {-88, -18}, {-88, -62}, {-72, -62}}, color = {0, 0, 0}, smooth = Smooth.None));
connect(rotor.flange_n, torq.flange) annotation(Line(points = {{-52, -62}, {-32, -62}}, color = {0, 0, 0}, smooth = Smooth.None));
connect(torq.tau, trsSignal.y) annotation(Line(points = {{-12, -62}, {4, -62}}, color = {0, 0, 127}, smooth = Smooth.None));
annotation(Documentation(info = "

up users guide

"), experiment(StopTime = 1, Interval = 0.2e-3), uses(PowerSystems(version = "0.4.0"), Modelica(version = "3.2.1")), Diagram(coordinateSystem(preserveAspectRatio = false, extent = {{-100, -100}, {100, 100}}), graphics)); end Inverter2;

What is the problem?
cattura

Inertial frame not working on generic components?

I've seen that switching refType from inertial to synchronous changes signals (e.g. voltages) from oscillating to constant (when systems are in steady state), that is totally satisfactory: it is like switching from Clarke to Park transform.

I tried some PowerFlow.GenericComponentsTest models, also. In these cases, instead the quantities remain constant (i.e. do not oscillate) in inertial mode, which seems to be wrong.

Take for instance FixedLoadTest: switching from Synchron to Inertial does not change anything in the shape of signals.
Is this an issue or there is something I'm disregarding?
I tried this on the 2016-06-11 version of the library.

Unit of measure

In PowerSystems.Control.Modulation.Partials.PWMasynBase

I read this:
parameter SI.Frequency dtmin(min=Modelica.Constants.eps,max=0.1*del_t)=1e-6
"minimal time between on/off";

It should be a Time, not a frequency.

Variable n_r

Hi!

some models in OM (for example PowerSystems.AC3ph.Machines) gives an error because the n_r vairable is no declared:

[1] 11:24:56 Translation Error
[PowerSystems.AC3ph.Machines: 2208:3-2208:47]: Could not evaluate structural parameter (or constant): n_r which gives dimensions of array: L_r[n_r]. Array dimensions must be known at compile time.

[2] 11:24:56 Translation Error
Error occurred while flattening model PowerSystems.Examples.Spot.AC3ph.Machines

how can be solved?

Thanks for this library!

Regarding PQload

In the latest version the PQload module was added. Its documentation page states:
PQ steady-state load
Steady-state load with constant characteristic.
Consumes the desired active and reactive power.

Can this model be used in transient simulation (e.g. System.dynType = SteadyInitial) by using controlled generators and none source?
Even if it is possible, is it recommenced?
Why was this model missing from the previous versions although it is probably the simplest one?

Thank you in advance

Two issues with AC3ph.Load

Consider Examples.Spot.AC3Ph.Load.
In it, meter can show quantities in V or p.u.
Try to execute the model with meter's puUnits first true, then false.
Is its observed that the results show no difference! After some analysis it results to be true, dince the applied voltage is 1V, and the meter's V_nom is 1 V.

I propose to reformulate the example so that when SIUnits are used different values are shown (e.g. 100V).
So the usage one Volt in this example is the first issue.

When trying to change the model, I found it confusing having for load V_nom do be specified in kV, and S_nom in VA. Either use V and VA, or kV or MVA.
So, the choice of units of measure for load nominal voltage and nominal power is the second issue.

Understanding how AC1phDC works

To help understand how AC1ph_DC models work, I've prepared "CompareMSL.mo", that I enclose.
It contains twin Power System and MSL models of a simple Ac1ph_DC system.
I've added some "info" explaining the model.

Now to me everything is clear. But I had some difficulties in getting to this result.
Just if this model it is deemed useful also for other users, I enclose it here.
I would be glad if it is added in the Ac1ph_DC.Elementary set of examples.

model CompareMSL
  "Comparison of a simple AC1ph_DC system with MSL counterpart"
  import PowerSystems;
  import Modelica.Constants.pi;

  inner PowerSystems.System system(refType=PowerSystems.Types.ReferenceFrame.Inertial,
      dynType=PowerSystems.Types.Dynamics.FixedInitial)
    annotation (Placement(transformation(extent={{-100,30},{-80,50}})));
  PowerSystems.Blocks.Signals.TransientPhasor transPh(ph_start=-2.0943951023932,
      ph_end=-2.0943951023932)
    annotation (Placement(transformation(extent={{-52,16},{-32,36}})));
  PowerSystems.AC1ph_DC.Sources.ACvoltage uAC(use_vPhasor_in=true, V_nom=
        10000)
    annotation (Placement(transformation(extent={{-20,-10},{0,10}})));
  PowerSystems.AC1ph_DC.Impedances.Inductor ind(
    S_nom=1e6,
    r={0.6,0.1},
    V_nom=10000,
    xm=0.1)
    annotation (Placement(transformation(extent={{44,-10},{64,10}})));
  PowerSystems.AC1ph_DC.Sensors.PVImeter meter(
    S_nom=1e6,
    puUnits=false,
    V_nom=10000)
    annotation (Placement(transformation(extent={{10,-10},{30,10}})));
  PowerSystems.AC1ph_DC.Nodes.GroundOne grd1
    annotation (Placement(transformation(extent={{-76,-10},{-96,10}})));

  PowerSystems.AC1ph_DC.Nodes.Ground grd
    annotation (Placement(transformation(extent={{80,-10},{100,10}})));
  Modelica.Electrical.Analog.Sources.ConstantVoltage uDC(V=1000)
    annotation (Placement(transformation(extent={{-42,-10},{-62,10}})));
  Modelica.Electrical.Analog.Sources.ConstantVoltage uDCsl(V=1000)
    annotation (Placement(transformation(
        extent={{-10,-10},{10,10}},
        rotation=-90,
        origin={-44,72})));
  Modelica.Electrical.Analog.Basic.Ground ground
    annotation (Placement(transformation(extent={{70,32},{90,52}})));
  Modelica.Electrical.Analog.Sources.SineVoltage uACsl(
    V=sqrt(2)*10e3,
    freqHz=50,
    phase=-0.5235987755983)
    annotation (Placement(transformation(extent={{-4,72},{-24,92}})));
  Modelica.Electrical.Analog.Basic.Resistor resistor(R=60)
    annotation (Placement(transformation(extent={{8,74},{28,94}})));
  Modelica.Electrical.Analog.Basic.Resistor resistor1(R=10)
    annotation (Placement(transformation(extent={{8,50},{28,70}})));
  Modelica.Electrical.Analog.Basic.Ground ground1
    annotation (Placement(transformation(extent={{-54,38},{-34,58}})));
  Modelica.Electrical.Analog.Basic.Transformer line(
    L1=100/(2*pi*50),
    L2=100/(2*pi*50),
    M=10/(2*pi*50)) annotation (Placement(transformation(
        extent={{-10,-10},{10,10}},
        rotation=90,
        origin={52,72})));
equation 
  connect(transPh.y, uAC.vPhasor_in)
    annotation (Line(points={{-32,26},{-4,26},{-4,10}}, color={0,0,127}));
  connect(uDC.p, uAC.neutral)
    annotation (Line(points={{-42,0},{-31,0},{-20,0}}, color={0,0,255}));
  connect(uDC.n, grd1.term)
    annotation (Line(points={{-62,0},{-69,0},{-76,0}}, color={0,0,255}));
  connect(ind.term_p, meter.term_n)
    annotation (Line(points={{44,0},{37,0},{30,0}}, color={0,0,255}));
  connect(meter.term_p, uAC.term)
    annotation (Line(points={{10,0},{5,0},{0,0}}, color={0,0,255}));
  connect(ind.term_n, grd.term)
    annotation (Line(points={{64,0},{72,0},{80,0}}, color={0,0,255}));
  connect(uACsl.n, uDCsl.p)
    annotation (Line(points={{-24,82},{-34,82},{-44,82}}, color={0,0,255}));
  connect(resistor.p, uACsl.p) annotation (Line(points={{8,84},{2,84},{2,82},
          {-4,82}}, color={0,0,255}));
  connect(ground1.p, uDCsl.n)
    annotation (Line(points={{-44,58},{-44,62}}, color={0,0,255}));
  connect(resistor1.p, uACsl.n) annotation (Line(points={{8,60},{-8,60},{-24,
          60},{-24,82}}, color={0,0,255}));
  connect(line.p2, resistor.n) annotation (Line(points={{47,82},{46,82},{46,
          86},{46,84},{28,84}}, color={0,0,255}));
  connect(line.p1, resistor1.n) annotation (Line(points={{47,62},{46,62},{46,
          58},{46,60},{28,60}}, color={0,0,255}));
  connect(line.n2, ground.p) annotation (Line(points={{57,82},{58,82},{58,86},
          {58,84},{80,84},{80,52}}, color={0,0,255}));
  connect(line.n1, ground.p)
    annotation (Line(points={{57,62},{80,62},{80,52}}, color={0,0,255}));
  annotation (
    Documentation(info="<html>
<p>This example shows what happens when a mixed DC-AC signal is applied to an &QUOT;inductor&QUOT; component (actually a two conductor line with ground return).</p>
<p>Current i[1] and i[2] in AC terminals are the currents flowing in conductors 1 and 2, as can be verified also in the MSL version of the system.</p>
<p>The sum ind.i[1]+ind.i[2] can be seen also flowing in terminals of the DC part of Power Systems the model.</p>
<p>In the example provided the mutual between the two circuits is 10&percnt; of the inductance of each of them.</p>
<p><br><a href=\"modelica://PowerSystems.Examples.AC1ph_DC.Elementary\">up users guide</a></p>
</html>"),
    experiment(StopTime=0.2, Interval=0.0001),
    Diagram(coordinateSystem(extent={{-100,-20},{100,100}})),
    Icon(coordinateSystem(extent={{-100,-20},{100,100}})));
end CompareMSL;

Illegal call to zeros with negative argument

The call to zeros(n_q - 1) here:

(zr_q, zx_q) := z_matrix(n_q, x_q, xsig_s, r_s, zeros(n_q-1), xsig_rq, r_rq);

seems to come down to zeros(-1), if we resolve n_q:
final parameter Integer n_q=size(xsig_rq,1);

parameter SIpu.Reactance[:] xsig_rq=fill(0,0)

giving the expression zeros(size(fill(0, 0), 1) - 1) ==> zeros(-1), which is illegal (all arguments to zeros need to be >=0), or am I missing something?

More rational transmission Line data

Consider Examples.Data.Lines.
It contains twin line data for RXline components and PIline components.
The latter have the same info of the former, plus additional info regarding transverse susceptances and conductances.
A few comments on them:

  1. there is no need for this duplication: the more complete records can be used with RXline components without inconveniences. Thus I propose to leave in place only the more complete parameters, those having presently the underscore in the name
  2. the data do not have any info showing which geometry they refer to. This can be improved.
  3. duplication of data for the same line is risky. Consider for instance OHline_15kV1ph: is should contain the same data of OHline15kV1ph, plus additional susceptances and conductances. However, I read V_nom=132e3 which is apparently wrong. Consider Cable132 kV and Cable_132 kV: they should have the same x, which is not the case (0.8e-3 and 0.08e-3 respectively)

To contribute positively to this issue I attach here a OH line record with realistic data and info about the line geometry.

So I propose to:

  1. to eliminate the records without susceptance and conductance info, since they are a somewhat duplication
  2. progressively modify the supplied data using new data for which geometry is reported. One of them might be the one I propose here:

ItOHLine_132kV.txt

Note that I have a simple utility program which computes all the parameters for continuously transposed line from geometry and conductor data which I can share with anyone interested.

Unit of measure of PVImeter quantities

The model AC3ph.Sensors.PVImeter allows the variables it measures to be computed either in p.u. or S.I. units.
Consider visualization in S.I. (puUnits=false). It works well, but quantities are plotted their units are shown as the quantities were p.u.
Consider for instance Examples.Spot.AC3ph.Breaker, run with puUnits=false. Near the end of transient meter.v[1] is 1.0e4. The unit on the vertical axis says "V/V", but it should be "V". The same error occurs on meter's powers and currents.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.