"External Variables" and "Internal Variables" in iPSL

[MaximeBaudette]

I stumbled upon a mistake in the PSAT LOADPQ model concerning the equations related to the change of base.

In all models of the iPSL the following convention must be respected and correctly implemented:

• Power Flow data should be entered with the following units (from pfComponent)
  • V_0 in pu
  • angle_0 in degrees
  • P_0 in MW
  • Q_0 in MVAr
• Interface variables ( or display variables) (used in the equations involving p.vr, p.vi, p.ir, p.ii)
  • v in pu (using the bus nominal voltage as base)
  • angle_v in degrees
  • P in pu (system base)
  • Q in pu (system base)
• Internal variables (component variables):
  • v in pu (using the voltage rating of the component)
  • angle_v in whatever you want as long as you specify it and do appropriate conversions
  • P in pu (Machine base)
  • Q in pu (Machine base)

Also we should find a naming convention to distinguish the "internal variables" form the "interface variables", so we don't mix them. I propose the suffix "_int", so we have: v_int, angle_v_int, P_int, Q_int (if there is a need for such internal variables, not all component require it)

[janlav]

• I would suggest that in the power flow-data, we should denote the voltage phasor angle as angle_V_0 (instead of angle_0) in order to be consistent with the interface variables (giving V_0,angle_V_0)
• Also, we should use either v or V to denote the voltage for interface variables and internal variables. I would suggest V (and consequently angle_V) to make it consistent with how power flow data is denoted.

[tinrabuzin]

@janlav @MaximeBaudette

• I'd like to stick with the current naming of the power flow data since I spent about a lot of time implementing it this way in all of the models. Also, it was agreed on Trello that we'll do it like this.
• I agree with the naming of interface variables. Maybe we can, to comply with the Jan's comment, use only angle instead of angle_v
• I'm fine with using suffix _int

Aslo I agree with Jan about the capital V for voltage since capital letters are used to denote RMS value of the vector(phasor) and that's what we're using it for.

[MaximeBaudette]

@tinrabuzin

I'd like to stick with the current naming of the power flow data since I spent about a lot of time implementing it this way in all of the models. Also, it was agreed on Trello that we'll do it like this.

I don't think this is a valid point to say that it will imply redoing a lot of changes... I know the feeling, but still, the goal is to have a coding convention that is logical, coherent and transparent to the user.

[MaximeBaudette]

I think we should have the following names:

• Power Flow data: V_0, Angle_V_0, P_0, Q_0
• Interface variables V, Angle_V, P, Q
• Internal variables V_int, Angle_V_int, P_int, Q_int

[petitrenaudseb]

@MaximeBaudette You are not coherent in the unit you define from the power flow data: you use pu for the voltage and SI units for the other inputs, why ? i think we should use SI units for each inputs : KV, degree, MW, MVar !

[dietmarw]

Just my two cents. Try to avoid Mx or kx as base units. Stick to the SI units and rather use Mega and kilo for display units. I've seen a lot of models getting into "scaling hell" because it was not clear that a power was expected in MW rather than W. Also Dymola offers nice UI help to actually enter M or k values as long as it knows the type (which is the case for power). As for naming, its quite common to use non-capital unit names for pu quantities and capital unit names for SI unit. That way it becomes clear what system you are working at just by looking at the quantity name. E.g., p and P_0 in your listing. And to be consistent I would then choose Angle instead of angle but because of the deg<-> radiant problematic would go one step further and simply call it AngleDeg which is unambiguous (in MSL the type is catually called Angle_deg but I try to avoid unnecessary underscores since they are treated in a special way by some tools for display purposes, incl Dymola) (see Modelica.UsersGuide.Conventions.ModelicaCode.Naming, section 1)

[MaximeBaudette]

@petitrenaudseb When I proposed the units, a long time ago, I did with the intention of picking an option that would lead to the least confusion. At that time there was often confusion between the per unit in the system base and machine base, hence the power in physical units.

I am of course open for discussion. Maybe we could reinstate the power flow data in per unit for everything, but then we need to agree on how to mark the per unit in the system base (for power flow data), and per unit in the machine base .

[MaximeBaudette]

@dietmarw MW and kV is a must, we can't go for something else than that, as it is the de facto standard units... Degrees vs radians is more open for debates, having received a French education, I'm very accustomed to using radians, but after using different proprietary tools for power systems, it seems like degrees are more standard in the domain

[dietmarw]

@MaximeBaudette I understand, but just thought to mention that you can have the UI using MW and kV whilst all calculations "below" are using the base units.

[petitrenaudseb]

@MaximeBaudette it's true that there is always a confusion between system base and machine base (and this problem must be tackle inside a model) But, in the ITESLA project, the internal data exchange format (IIDM) uses SI units for each load flow results, so perhaps we should be conform with that @dietmarw In power system community, the real unit used are KV,MW,MVAR and degree

[MaximeBaudette]

@dietmarw No, in our case the calculations "below", are done in the following units:

• in per unit of the machine base for all equations internal to a component (gens, loads, etc...)
• in per unit of the system base for all equations related to the network (connections of component to the network, lines, trafos, etc.)

This per uniting system is very not like in any other field, and therefore is very against established standards... But good luck getting a power engineer understand equations using SI units ;-)

@petitrenaudseb Yes, we could use kV,MW,MVAr and degree. A wild guess as to why it is like this in the current power flow results, is that it is like in PSSE...

About the two kinds of per unit, I agree it should be tackle within each model, but I am wondering if we shouldn't agree on a way to distinguish the two in the unit description (like p.u. and p.u. component base)

[lvanfretti]

@MaximeBaudette @dietmarw not using p.u. in equations can cause computation problems, there are some ancient papers that talked about this... I don't remember too well, I will have to ask a colleague. Anyway for this reason, if you look at the de facto proprietary tools, internally after receiving the data in SI they would have a module to change to per unit; some of them even give you the option to provide per unit data directly. I'll try to get the papers to see if the computation aspect is a good reason to keep per unit equations, but my feeling is that this will make very hard for users to follow as most texts, and education in the greater part of the world is done assuming per unit quantities.

On the other hand, I think there should be a way in Modelica to map the per-unit into SI before/after calculations if a user wants to display simulation results in both?

@petitrenaudseb I don't think that because internally iTesla stores in SI, then we have to do it also in the library.

Regarding p.u. types, I guess we have to distinguish clearly to avoid ambiguity for the user.

[MaximeBaudette]

@lvanfretti Modelica is not very helping when it comes to unit management. With @tinrabuzin we looked into units and type declarations for using the unit management of Modelica, but after reading the Modelica documentations, it appeared that Modelica doesn't care about units at all, they only provide the fields for putting the unit information. The unit management is actually implemented within the Modelica tool, that provides unit conversions for GUI and graphical facility. While this is fine when you only use SI units, in our case where we have to define two new units (p.u. in machine/ system base), it means we can't have the dynamic conversion in the GUI to fill in the parameters or in the graphical facility for the plots.

@tinrabuzin and me were really disappointed by that yesterday...

[dietmarw]

Of course pu is no problem at all. And having the equations in pu is neither a problem. I was not suggesting replacing pu equations with SI equations but trying to avoid M- k-SIunit based equations and rather stick to the base units in those equations if they exist. If everything is in pu anyway then this is a non-issue. Then it's probably just down to how the SI parameters are entered and if MW and kV are the domains standard units then it probably makes sense to use them. Internally they are going to get converted to pu any way. This can also be done dynamically for the user. You can find examples in the old Spot library, where the user has the choice to enter data in SI or pu.

[dietmarw]

@MaximeBaudette We cross-posted there. It is possible to handle units properly in Modelica also independent of the tool. So you could let the user decide which base system he wants. In the Spot example above there is only a choice between SI and pu, but you could easily introduce "SI | pu_machine | pu_system". On the tool side, if you always use proper unit definitions instead of simply Real they can help you resolving unit conflicts. But that part is, as you correctly pointed out tool dependent. Same goes for displayUnit support which OMEdit currently does not have if I'm not mistaken.

[sjoelund]

@dietmarw @adeas31 OMEdit does not support display units, but OM has some limited support for scaling via convertunits so it should be possible enhance OMEdit to handle these conversions...

[MaximeBaudette]

@dietmarw What I meant was that, yes we can use the facility offered by the Modelica language for adding unit information in parameter and variable list by defining our own types, but we can't use the goodies like automatic conversions in the GUI or plotting parts. Unless Modelica defines pu as a SI unit (where you could define the base) ? I would expect them to have it, but haven't really found it yet.

Anyway, whether or not we can have the conversion, I was thinking of ditching our current way of indicating units in parenthesis, and go for types and unit annotations.