Coordinate system transformations

[FHell]

When thinking about various design questions for the operating point and the three phase model it occurred to me that it might be valuable to allow for a change of the co-rotating frame. This would require every node to explicitly include a variable/parameter \omega_r, and express the equations in such a way as to be universally valid (for example by multiplying e^{i \omega_r t} at appropriate points).

The advantage of this would be that we could vary the \omega_r in the operating point search, and that we would have a clear definition for our dq0 system in terms of our rated frequency.

I'm not sure how much work that would be or how worthwhile it would really be to really do this though...

[SabineAuer]

I discussed a similar thing (I think) recently. To always have a local voltage variable and a global (network side) voltage variable. Then you transform between the two. I heard this ways you could also easier parallelize the simulations of different nodes. Am I pointing at something similar as you do?

[FHell]

I don't understand the parallelization argument, but I think it's similar, and it could be one way to implement this. Have one global reference frequency and look at equations relative to that.

My main motivation was thinking about the Pi Model, where we do things like the capacitor equation:

I = C dV/dt

In a rotating frame \omega_r with I' = I e^{- i \omega_r t} this becomes:

I' = i C \omega_r V' + dV'/dt

If \omega_r is the equilibrium frequency then the relationship between I' and V' becomes algebraic in the equilibrium. But really it's a relationship between the equilibrium frequency, I' and V'. Of course if we don't vary the frequency much it's a fine approximation to keep it fixed at 50Hz/60Hz, but it could help with initializing the system at operation points to allow flexibility here.

After reviewing some of the inverter things, it might not be very useful for local dq0 systems where we want to simulate the behaviour of the PLL though....

[luap-pik]

I renamed the issue since I believe the topic is more general.
We should implement the coordinate transformations (Park trafo)
as methods that convert states. Also, the issue of returning single-phase
vs. three-phase values (all in the balanced case though) remains.

Whether components should be allowed to have their local coordinate system, I'm not sure.
At the end, we need to go to a common frame for the simulation anyway, right?
It might be more straight-forward to offer conversion functions.

For instance, it would be a good introspective feature to look at simulation output
transformed to e.g. the ABC system and so on.

Further, in the comparison with powerfactory, we repeatedly came accross the issue that e.g. currents are measured and stated as a single-phase value by convention. Since PD gives you the three-phase values, you "randomly" have to divide by factors of sqrt(3).

[SabineAuer]

I think we indeed repeatedly use different kinds of transformations. Like the Park transformation (or dq-transformation: https://de.wikipedia.org/wiki/D/q-Transformation) going from global αβ-coordinates to local dq-coordinates, e.g. here and [here](https://github.com/JuliaEnergy/PowerDynamics.jl/blob/dfcd8fb8bb6cc270fcbd846419fd1cfd33d44d51/src/nodes/experimental
/WindTurbineGenType4_RotorControl.jl#L22) with the help of a PLL.
And we could indeed implement this as a general transformation available to all components.

As far as I understood it is very usual to use global and local coordinate systems since this is also what a for example controller "sees" in real life measuring the phase signal with a PLL. What do you mean with the common frame for the simulation? We have the global coordinate system after all.

I do not know, yet, what you suggest to do with the issue of three-phase and single-phase signals. You want to include correction factor (sqrt(3)) rigorously or something else?

[luap-pik]

Oh, with the three-phase I just thought that there could be functions like get_dq_current or
get_single_phase_current and conversion functions which act on States, implementing the correct factors of sqrt(3).

With the common frame, I thought that all entries in the state vector should have the same reference when since they are exchanged between the components. (That's the situation now as well, I think.) Internally, of course, there can be any transformation.

In general, however, we could also have each component to specify which input/output it accepts and have automatic conversions between them. But I'm not sure if it's useful for something.

[SabineAuer]

conversion functions sounds like a good idea in order to implement the correction factor.

Concerning the common frame: I think, we are indeed using the same global frame as input for components. Maybe I cannot follow you here? For this point and the input/ output specification: maybe an example would help?