Base for the SM excitation current

[ceraolo]

I see that PowerGrids library proposes examples from IEEE, so I expect it to be written having IEEE 421.5 in mind.
In Annex B of IEEE 421.5-2005 (IEEE 421.5-2016 says the same) I read:
one pu generator field current is that current required to produce rated synchronous machine terminal voltage on the air-gap line, and one pu field voltage is the corresponding field voltage.

This implies that in steady-state the ratio field voltage/field current must be always 1, for linear machines such as PowerGrid's.

In PowerGrid's ENTSOE-TestCase1 I see in the first times (when the machine has no load), ufPuIn=1.0000 and ifPu=0.540541, so the ratio is 1.85. Where does this value come from?

A correct pu value for field currents is important if one wants to use exciters requiring it. I'm currently working on ExcAC6A, which needs this current, but also IEEE_ST4B, included in PowerGrids, receives it as input.

Do I miss something?

[ceraolo]

My quotation of IEEE 421.5-2005, in this ticket's description leaves some doubts on how to interpret 1 pu field current and voltage.

What 421.5-2016 says clarifies that when we have 1 pu on the generator field current, we should have 1 p.u. on the no-load air-gap line (fig. B.1 of IEEE 421.5-2016).
Therefore, for linear machines, 1pu on the excitation would mean 1 p.u terminal voltage under no-load conditions.
Moreover, to have 1 p.u. field current we should have (in steady state) 1 p.u. excitation voltage.

[casella]

What 421.5-2016 says clarifies that when we have 1 pu on the generator field current, we should have 1 p.u. on the no-load air-gap line (fig. B.1 of IEEE 421.5-2016). Therefore, for linear machines, 1pu on the excitation would mean 1 p.u terminal voltage under no-load conditions.

Yes.

This is exactly what happens in test PowerGrids.Electrical.Test.SynchronousMachine4WindingsNoLoad: the excitation voltage is set to 1 p.u. constant, the machine is not connected to anything (so it's zero-load by definition) and the port voltage is indeed VPu = 1. In this case, excitationPuType =nominalStatorVoltageNoLoad

See also the documentation of the SM model.

PowerGrids.Examples.ENTSOE.TestCase1 has excitationPuType = Kundur, which uses the same base of the stator as explained in Kundur's book, so ufPu is very small, around 0.0007. This model works with AVR control, which has some static error, and a reference for VPu which is not 1 p.u., so it's not surprising that you don't get 1 VPu at the machine port. In any case, the excitation voltage is not 1 p.u. here, so there's no reason why the no-load port voltage should be 1 p.u.

Do I miss something?

[ceraolo]

In my version in PowerGrids.Examples.ENTSOE.TestCase1 I have excitationPuType =nominalStatorVoltageNoLoad, so U=1p.u. with Uf=1 p.u., which is ok.

But IEEE indicates that in steady-state when I have Uf=1 p.u. I should have also If=1 p.u, while here we have ifPu=0.540541. This is what this ticket is about (see its name).

[casella]

@ceraolo, I missed that you were worried about the excitation current, sorry about that.

In PowerGrid's ENTSOE-TestCase1 I see in the first times (when the machine has no load), ufPuIn=1.0000 and ifPu=0.540541, so the ratio is 1.85. Where does this value come from?

The declarative equation-based approach makes it easy to find out, simply by reading the model's source code. That's why I strongly believe the Modelica approach to modelling is superior to traditional Fortran or C/C++ based codes 😄

• ufPu is defined here as having a base voltage as per the Kundur book (the same base voltage used for the rotor voltages, if I recall correctly).
• ifPu is defined here. There is no explicit reference to Kundur's book, but that's implicit, since the whole model is declared to be written according to Kundur, except for the nomenclature that is taken from Eurostag, because of RTE writing the original specs.
• the conversion between IEEE and Kundur's base voltage takes place here, with kuf being set here.
• no such conversion is made for the current ifPu, which is thus always meant to have the same base value as all other rotor currents, according to Kundur
• according to this equation, the steady-state ratio between ufPu and ifPu is rfPu, which is not necessarily one, and it's given according to Kundur's base rotor quantities. That's where the 1.85 factor you mention eventually comes from.

The truth is, when we wrote this model in 2019, all we did care about was the base unit of the excitation voltage, because that is used by all AVR algorithms, and people are used to IEEE base unit for that. We didn't care much (in fact, we didn't care at all) about the corresponding excitation current, so we left it in Kundur's base units.

[casella]

Proposal: we can introduce a ifPuOut output with the appropriate conversion factor, so that when excitationType = nominalStatorVoltageNoLoad also the base current is changed to give ifPu = 1 p.u. in no-load conditions when ufPu = 1.

BTW, we could exploit the 1.0.2 -> 2.0.0 non-backwards compatibility to rename this option excitationType = IEEE421_5, if that is a popular reference.

[casella]

Now that OMEdit supports conditional connectors, we could also alternatively provide a physical DC port for the excitation voltage/current interface, as we discussed some time ago when I visited UniPi. But then I think we should use Volt and Ampere, not p.u., as with all other physical ports.

Anyway, this is another story that does not belong to this ticket. @ceraolo feel free to open another one about this feature so we don't forget about it.

[ceraolo]

option excitationType = IEEE421_5, if that is a popular reference.

yes, I think it is a popular reference, so this name change could make sense

[ceraolo]

Anyway, this is another story that does not belong to this ticket. @ceraolo feel free to open another one about this feature so we don't forget about it.

I remember well this discussion.
For instance MSL SM_ElectricalExcited has terminals for excitation.
I like the idea of using physical connectors for excitation, but we must see whether from the Park's standard matematical description, E.g. Kundur's, we can get the needed equations to implement it, and wheter from the usually available Park parameters we are able to infer everything we need.

I'll try to make some checks on this.

It is a fact that the commonly used models in Power systems tend to reason in p.u. as the IEEE 421.5 story tells us. I think this is maybe a residual from the past, when physical simulators did not exist, but, on the other hand, I'm afraid it is not an easy task to go against this (so widespread) way of thinking.

[casella]

I remember well this discussion. For instance MSL SM_ElectricalExcited has terminals for excitation. I like the idea of using physical connectors for excitation, but we must see whether from the Park's standard matematical description, E.g. Kundur's, we can get the needed equations to implement it, and wheter from the usually available Park parameters we are able to infer everything we need.

The excitation circuit has a DC interface and DC behaviour, we just need to multiply the p.u. variables for the appropriate base quantities. No big deal.

It is a fact that the commonly used models in Power systems tend to reason in p.u. as the IEEE 421.5 story tells us. I think this is maybe a residual from the past, when physical simulators did not exist, but, on the other hand, I'm afraid it is not an easy task to go against this (so widespread) way of thinking.

We could of course define p.u. DC ports. But then we need to basically re-do the whole Modelica.Electrical.Analog library with p.u. variables. And then we're back to square one, where one never knows what is the base quantity and it's very easy to mess up. Which is exactly what we did not want to do when we decided to use physical quantities (not p.u.) at the terminalAC connectors of PowerGrids.

After almost five years playing around with these models, I am even more convinced that p.u. make sense locally (e.g. for a synchronous machine model), but not globally, where you eventually end up with questionable ideas as using 100 MW as base quantity for a whole power system (why 100 and not 200?) or, even worse, end up having p.u. variables with different bases all over the place. The transformer model of iPSL is one such example. Something as simple as a transformer becomes horribly complicated and totally obscure. I'd rather avoid that, if possible.

I would therefore find it a bit odd if we introduced p.u. physical connectors for such excitation circuits.

[ceraolo]

We could of course define p.u. DC ports. But then we need to basically re-do the whole Modelica.Electrical.Analog library with p.u. variables

I would never want this.

I am even more convinced that p.u. make sense locally (e.g. for a synchronous machine model), but not globally,

When computer programs are concerned, I agree.
For manual computations, instead, global p.u. allows analysing systems which otherwise would be too complex to solve.

I would therefore find it a bit odd if we introduced p.u. physical connectors for such excitation circuits.

I would never want this.

I would gladly welcome an electric port (of the type in MSL Electrical.basic) for excitation connection, given that we can do this using Park's model, and that all the needed variables (such as the excitation circuit resistance) are available from manufacturer's data. I mean an electric port where voltages are in volt, currents in ampere.

[ceraolo]

we just need to multiply the p.u. variables for the appropriate base quantities. No big deal.

Good. I must admit that I feel I've to check something to see how to infer base quantities for excitation voltage and current, from the nominal data of the machine.

[casella]

I re-read Kundur's book, Section 3.4. To make things more confusing, he uses peak current and voltage whereas we use RMS current and voltage, but I guess this only changes how you compute power (we have a factor 3, Kundur has a factor 3/2) and should be irrelevant for the topic of this ticket.

As I understand, the power base for the rotor is the same as for the stator. The current base is i_fd,base = L_ad/L_afd*i_s,base. Unfortunately, while L_ad is the MdPu parameter of PowerGrid's synchronous machine model, I'm afraid L_afd is missing from the parameter list. As I understand, this parameter is really not required to write the p.u. equations. Apparently, it would instead be required to know what is the actual current flowing into the excitation circuit.

Please double-check.

[ceraolo]

I'm afraid it is not an easy task to go against this (so widespread) way of thinking.

what I wanted to say here is that all IEC and IEEE governors and AVRs mix the control part with the representation of turbines and exciters, and represent these mixes in terms of block diagrams.
Reversing this, making physical what is physical and leaving cyber the control parts, is a very huge task, probably not worthing the effort.

[ceraolo]

we just need to multiply the p.u. variables for the appropriate base quantities. No big deal.

not only this. Presently the SM model is written in such a way that receives as input voltage and determines current.
With a physical interface it should be in principle possible have as input an imposed current (current generator) or an E-R pair, not just a fixed voltage. Would the present formulation the SM model be working of in these cases?

[casella]

Presently the SM model is written in such a way that receives as input voltage and determines current. With a physical interface it should be in principle possible have as input an imposed current (current generator) or an E-R pair, not just a fixed voltage. Would the present formulation the SM model be working of in these cases?

Absolutely. Modelica is a-causal. You just need to remove the input connector and put a DC pin with coupled voltage-current variables instead. Everything else remains untouched.

[ceraolo]

Absolutely.

Thank you for checking the SM code.

Modelica is a-causal.

Not always: it depends on how you write the code. For instance, the IEEE control blocks in PowerGrids are written in a casual way.

Since The SM model receives the excitation voltage as input, it is letigitimate to ask the question how it is internally written and how large the needed changes are to convert this in an a-causal way.

[casella]

Not always: it depends on how you write the code. For instance, the IEEE control blocks in PowerGrids are written in a casual way.

We never write anything in a casual way, we're always highly professional 😄

Seriously, there is no such thing as causal models in Modelica. The semantics of input and output connector is not related to causality (this is a common misunderstanding), it is just related to the balancing of models:

• every connection set involving inputs and outputs must always have only one output, and possibly may inputs
• when checking the balancedness of a model, one extra equation can be assumed for each input

see Section 4.7 of the MLS for a thorough discussion.

It is perfectly legitimate to take a model with an input and an output, assign the output, and compute the input backwards. You can find a short demo attached here: Causality.mo.txt

The Forward model connects a step signal source to the input of sys, a first-order system.

The Backwards model uses the Modelica.Blocks.Math.InverseBlockConstraints converter block to allow connecting a signal generator's output to the output of sys, without violating the connection constraints, and then tries to compute the inverse solution, i.e. the input signal that would give a step output response on system sys. Of course that cannot be computed, because it would be of impulsive nature. However, if the step signal that we'd like to see on the output is low-pass filtered to make it smooth enough, as in Backwards2, the models is solved successfully, and an approximation of the impulse is computed for sys.u.

Note that the equations of block sys are not changed, only the system boundaries are. Eventually, they will be solved in the opposite direction than the input and output connectors would imply.

There (almost) no causality in Modelica 😎. The only exception is that Modelica cannot handle impulses.

[ceraolo]

I understand all of your reasoning...
but sometimes one has to go beyond words to try to understand what his interlocutor means when they say something (often using imprecise words to save space).

Anyway. I don't see enough value for our time continuing discussing this.
We'll see what we can do with the SM model.

[casella]

At the end of the discussion, I would propose that we implement what was proposed here, i.e.:

• introduce an enumeration value explicitly mentioning IEEE 421.5
• introduce a p.u. output with the excitation current, which is computed with the appropriate conversion factor based on the select base. We need to figure out what is the appropriate numerical value to do that.