Model a PQU diagram for reactive limits

[alicecaron]

Describe the current behavior

Generators, dangling lines and battery at least have reactive limits. These reactive limits can be of two types currently:

• MinMaxReactiveLimits: determined by a minQ and maxQ
• ReactiveCapabilityCurve: determined by a minQ and maxQ per given P (active power)

Describe the expected behavior

We add a new implementation ReactiveShape that is able to model a 3D (P, Q, V) volume.
The volume is defined by a list of planes.
Each plane is described by an equation q + alpha * v + beta * p < OR > gamma
A detection algorithm is implemented to check if a given point (p, q, v) is inside the shape. (!!! there is probably some existing Java geometry libraries for that, to check otherwise to fully recode)

Describe the motivation

Model a volume of reactive limits for a generator for instance, depending on both the voltage and the active power.

Extra Information

Create a new ReactiveLimits implemenation allowing to compute minQ and maxQ according to given active power AND voltage. This may imply a refactor of the ReactiveLimits implementations + modify the iidm, allowng to define new kinds of reactive limit (a volume instead of only a reactive capability curve).

In addition to existing double getMinQ(double p) and double getMaxQ(double p) of ReactiveLimits, we add double getMinQ(double p, double v) and double getMaxQ(double p, double v). In case of calling its with just p with a ReactiveShape we use the current calculated v of the generator (bus.getV()). In case of no calculated v, an exception is thrown.

[snoopfab]

Can we agree that the volume expected must be a single convex polyhedron (or polytope) ?

The provided example code, which checks if a point satisfies a conjunction of linear inequalities, correctly defines such a region.

public boolean isInside(double p, double q, double v) {
    for (Plane plane : listOfPlanes) {
        double expression = q + plane.alpha * v + plane.beta * p;
        if (plane.relation == '<' && expression >= plane.gamma) {
            return false;
        }
        if (plane.relation == '>' && expression <= plane.gamma) {
            return false;
        }
    }
    return true;
}

Concerning getMinQ and getMaxQ with a given active power the computation would require solving a small linear programming problem hence are those functions really needed in computations when using ReactiveShape ?

Computing getMinQ and getMaxQ with a given active power and tension is significantly easier and could be implemented in a couple of lines.

Given this simple, constraint-based definition, using a complex geometry library may be unnecessary overkill for our current usage.

We probably should implement checks to detect invalid or degenerate inputs, which should trigger an error:

• Detcting Input constraints that define multiple, disconnected convex regions => may be hard to achieve simply
• An empty feasible region (e.g., conflicting constraints like two parallel planes pointing in opposite directions. => this may still require a linear solver

Concerning the scope of the:

limited to modelling Java + IIDM serialisation / deserialisation , validity checks and utility method to test if a p,v,q point is in the reactive limit envellope ? Or we should go further (usage in rao / openloadflow ?)

[geofjamg]

Can we agree that the volume expected must be a single convex polyhedron (or polytope) ?

yes

Concerning getMinQ and getMaxQ with a given active power the computation would require solving a small linear programming problem hence are those functions really needed in computations when using ReactiveShape ?

Why ? we can simply fixe the voltage to the current calculated voltage (the bus v attribute) if defined of fallback to the nominal voltage so that we always come back to a full (p, v) detection.

Given this simple, constraint-based definition, using a complex geometry library may be unnecessary overkill for our current usage.

Ok

We probably should implement checks to detect invalid or degenerate inputs, which should trigger an error:

Detcting Input constraints that define multiple, disconnected convex regions => may be hard to achieve simply
An empty feasible region (e.g., conflicting constraints like two parallel planes pointing in opposite directions. => this may still
require a linear solver

Good point. I agree than this is not simple but that we need to implement it anyway. Maybe an external library would embed this kind of check directly ?

limited to modelling Java + IIDM serialisation / deserialisation , validity checks and utility method to test if a p,v,q point is in the reactive limit envellope ? Or we should go further (usage in rao / openloadflow ?)

At first, yes we just validate with basic unit tests on powsybl core.
Then we will implement it in OLF (that should be straighforward) to really check that our design is good and easy to use in a simulator.

[snoopfab]

Thanks for your insights.

I was thinking to use apache common math3 that implements a simple primal simplex algorithm with slacks variables and infeasibility detection.
This would allow us to detect both degenerate inputs (when lp is infeasible we throw an empty polytope exception to the user).
By the way, this is already an existing dependency of powsybl math (from pom.xml):

<dependency>
    <groupId>org.apache.commons</groupId>
    <artifactId>commons-math3</artifactId>
</dependency>

Why ? we can simply fixe the voltage to the current calculated voltage (the bus v attribute) if defined of fallback to the nominal voltage so that we always come back to a full (p, v) detection.

We could use the linear solver to minimize and maximize Q under the feasible polytope region to compute them without needing to fix the voltage. But i don't know if this is really needed by olf or somewhere else.

[jeandemanged]

Hi,

Users are primarily power systems engineers. ReactiveShape doesn't tell what it is about immediately. I would prefer this new model to have the "PQU" present in the name, e.g. ReactivePqu. Or ReactivePquShape if you really want to keep shape in the name. For some generator types e.g. thermal, the temperature also comes into play into the real capability, so by introducing PQU in the name it is made clear it deals with PQU only, not T.
or ReactiveCapabilityShape in case some day we want more parameters than only PQU to compute the shape ?

[snoopfab]

@jeandemanged : That makes sense to me. @alicecaron : can you confirm the naming ?

[snoopfab]

As agreed on slack we'll gona use the ReactiveCapabilityShape naming

[snoopfab]

@alicecaron @geofjamg

Concerning the q + alpha * v + beta * p < OR > gamma equations there's no way to simply bound v and p independently from q as q has an implicit coefficient fixed to one.
Should'nt we let the user configure optionnal bounds on each variables without specifying hyperplanes ?

[geofjamg]

@alicecaron @geofjamg

Concerning the q + alpha * v + beta * p < OR > gamma equations there's no way to simply bound v and p independently from q as q has an implicit coefficient fixed to one. Should'nt we let the user configure optionnal bounds on each variables without specifying hyperplanes ?

There is already p (pmin, pmax on generator element) and v bounds (low_voltage_limit and high_voltage_limit in the voltage levele element) in the IIDM model