Calculations

Calculation types

With power-grid-model it is possible to perform three different types of calculations:

Power flow: a “what-if” scenario calculation. This calculation can be performed by using the calculate_power_flow method. An example of usage of the power-flow calculation function is given in Power flow Example
State estimation: a statistical method that calculates the most probabilistic state of the grid, given sensor values with an uncertainty. This calculation can be performed by using the calculate_state_estimation method. An example of usage of the power-flow calculation function is given in State Estimation Example
Short circuit: a “what-if” scenario calculation with short circuit entries. This calculation can be performed by using the calculate_short_circuit method.

Calculation types explained

Power flow

Power flow is a “what-if” based grid calculation that will calculate the node voltages and the power flow through the branches, based on assumed load/generation profiles. Some typical use-cases are network planning and contingency analysis.

Input:

Network data: topology + component attributes
Assumed load/generation profile

Output:

Node voltage magnitude and angle
Power flow through branches

See Power flow algorithms for detailed documentation on the calculation methods.

Regulated power flow

For most power flow calculations, the grid is fixed as the user dictates. However, in practice, the grid often contains regulators for certain components. When including those regulators in the calculations, the grid may be optimized according to the power flow results and the behaviour of the regulators.

See Regulated power flow calculations for detailed documentation on regulated power flow calculations.

State estimation

State estimation is a statistical calculation method that determines the most probable state of the grid, based on network data and measurements. Here, measurements can be power flow or voltage values with certain kind of uncertainty, which were either measured, estimated or forecasted.

Input:

Network data: topology + component attributes
Power flow / voltage measurements with uncertainty

Output:

Node voltage magnitude and angle
Power flow through branches
Deviation between measurement values and estimated state

In order to perform a state estimation, the system should be observable. If the system is not observable, the calculation will raise either a NotObservableError or a SparseMatrixError. In short, meeting the requirement of observability indicates that the system is either an overdetermined system (when the number of independent measurements is larger than the number of unknowns) or an exactly determined system (the number of independent measurements equals the number of unknowns). For each node, there are two unknowns, u and u_angle. Due to the relative nature of u_angle (relevant only in systems with at least two nodes), in total the following conditions should be met:

\[ n_{measurements} >= n_{unknowns} \]

Where

\[ n_{unknowns} = 2 \cdot n_{nodes} - 1 \]

The number of measurements can be found by taking the sum of the following:

number of nodes with a voltage sensor with magnitude only
two times the number of nodes with a voltage sensor with magnitude and angle
two times the number of nodes without appliances connected
two times the number of nodes where all connected appliances are measured by a power sensor
two times the number of branches with a power sensor and/or a current sensor

Note

Having enough measurements does not necessarily mean that the system is observable. The location of the measurements is also of importance, i.e., the measurements should be topologically independent. Additionally, there should be at least one voltage measurement.

Note

Global angle current measurements require at least one voltage angle measurement to make sense. See also the current sensor component documentation.

Note

It is not possible to mix power sensors with current sensors on the same terminal of the same component. It is also not possible to mix current sensors with global angle measurement type with current sensors with local angle measurement type on the same terminal of the same component. However, such mixing of sensor types is allowed as long as they are on different terminals.

Warning

The iterative linear and Newton-Raphson state estimation algorithms will assume angles to be zero by default (see the details about voltage sensors). In observable systems this helps better outputting correct results. On the other hand with unobservable systems, exceptions raised from calculations due to faulty results will be prevented.

Necessary observability condition

Based on the requirements of observability mentioned above, users need to satisfy at least the following conditions for state estimation calculation in power-grid-model.

n_voltage_sensor >= 1
If no voltage phasor sensors are available, then both the following conditions shall be satisfied:
- There are no global angle current sensors.
- n_unique_power_or_current_sensor >= n_bus - 1.
Otherwise (if there are voltage phasor sensors available, one will be reserved as reference), the following condition shall be satisfied:
- n_unique_power_or_current_sensor + n_voltage_sensor_with_phasor - 1 >= n_bus - 1

n_unique_power_or_current_sensor can be calculated as sum of following:

Zero injection or zero power flow constraint if present for all nodes.
Complete injections for all nodes: All appliances in a node are measured or a node injection sensor is present. Either of them counts as one.
Any sensor on a Branch for all branches: Parallel branches with either side of measurements count as one.
All Branch3 sensors.

Sufficient observability condition

The condition check above only checks the necessary condition for observability. When the measurements are not independent enough, the system may still be unobservable even if the necessary condition is met. The power-grid-model performs the sufficient condition check on radial networks. The power-grid-model performs the sufficient condition check on meshed networks without voltage phasor sensor.

The sufficient check is done by the topological approach of finding a full spanning tree with the available sensors at components in the network. That is to say, if there exists a tree that visits all nodes in the network, the network is observable.

Warning

The handling of voltage phasor sensor in the context of observability check is still work in progress. When there is more than 1 voltage phasor present in a meshed network, the sufficient check will pass the network through to the state estimation calculation directly.

In this case, the validation of the independent measurements is rather straightforward. If the system is not observable, the calculation will raise a NotObservableError instead of SparseMatrixError.

Short circuit calculations

Short circuit calculation is carried out to analyze the worst case scenario when a fault has occurred. The currents flowing through branches and node voltages are calculated. Some typical use-cases are selection or design of components like conductors or breakers and power system protection, e.g. relay co-ordination.

Input:

Network data: topology + component attributes
Fault type and impedance.
In the API call: choose between minimum and maximum voltage scaling to calculate the minimum or maximum short
circuit currents (according to IEC 60909).

Output:

Node voltage magnitude and angle
Current flowing through branches and fault.

Note

Short-circuit calculations are currently implemented in the phase (abc) domain and therefore require a grounded configurations in certain cases, similar to asymmetric power flow calculations. For details on how floating grids are treated in power-grid-model, please refer toFloating grid handling.

Common calculations

Power flowing through a branch is calculated by voltage and current for any type of calculations in the following way:

\[ \underline{S_{branch-side}} = \sqrt{3} \cdot \underline{U_{LL-side-node}} \cdot \underline{I_{branch-side}}^* \]

These quantities are in complex form. Hence, they can be constructed by PGM output attributes in the following way:

For \(\underline{U}\) of nodes, u is the magnitude and u_angle is the angle. Also the line to neutral voltage can be converted into line to line voltage by \( U_{LN} = U_{LL} / \sqrt{3}\). Check Node Steady State Output to find out which quantity is relevant in your calculation.
For \(\underline{I}\) of branches, i_side is the magnitude. Its angle can be found from p_side and q_side by: \(\arctan(\frac{P_{side} + j \cdot Q_{side}}{\underline{U}})^{*}\). The side here can be from, to for Branches, 1, 2, 3 for Branch3s.

Symmetric vs asymmetric calculations

Power-grid-model can solve the grid either as a balanced single-phase equivalent (symmetric) or in full three-phase detail (asymmetric). The option affects which attributes are required and how results are exposed.

Symmetric calculations (symmetric=True, default): Assume a perfectly balanced three-phase system so every phase shares the same voltage and current. The solver builds a positive-sequence network using r1, x1, c1, … parameters and collapses any asymmetric appliance to a single equivalent (asymmetric loads/generators are averaged across phases as described in Component Type Hierarchy and Graph Data Model). For symmetric calculations voltages are given as line-to-line and the output contains single values for all output variables.
Asymmetric calculations (symmetric=False or any non-three-phase fault): Builds a full \(abc\) nodal admittance matrix and solves each phase separately. Next to the positive-sequence parameters, the model now also needs the zero-sequence parameters (e.g. r0, x0, c0), or per-phase parameters (r_matrix & x_matrix) for asym_line; symmetric components are expanded by evenly splitting their totals across the three phases. For asymmetric calculations voltages are given as line-to-neutral and output contains arrays with values per phase for all output variables.

Note

In power-grid model, asymmetric calculations with certain configurations require the network to have a reference to ground. For details on how floating grids are treated in power-grid-model, please refer to Floating grid handling.

Note

For short-circuit calculations, a three-phase fault_type is calculated with a symmetric calculation, while any other fault_type (e.g. single- or two-phase faults) automatically triggers the asymmetric calculation. Outputs for short circuit calculations always give asymmetric output, independent of the fault type present.

Floating grid handling

In power-grid-model, two different concepts should be distinguished:

Physical grounding of the network Whether the electrical system has an explicit path to ground (e.g. via transformer winding connection, shunts, or grounding elements).
Numerical solvability in PGM Whether the formulation provides enough reference to compute a unique solution, even if the physical system is not explicitly grounded.

A floating grid issue only arises in specific configurations where:

A transformer is present, and
All involved windings are ungrounded (no star-point grounding, no delta grounding reference, etc.), and
No other grounding path (shunt, source grounding, etc.) exists in the network.

In this case, the system may lack a reference for calculating line to ground voltages, leading to an ill-posed or singular system.

Currently in power-grid-model, a shunt with small admittance is added only in transformer-related configurations where a grounding reference is missing. This shunt is connected to one side of the transformer. This is intended to ensure numerical solvability in cases where the transformer topology introduces an ungrounded subsystem.

Power flow algorithms

Two types of power flow algorithms are implemented in power-grid-model; iterative algorithms (Newton-Raphson / Iterative current) and linear algorithms (Linear / Linear current). Iterative methods converge to accurate solutions through multiple iterations and should be selected when accurate results are required. Linear approximation methods perform a single iteration and are significantly faster, but their accuracy depends on grid conditions and may vary. The table below summarizes the convergence characteristics and typical use cases for each algorithm to help you pick the right one.

At the moment, the following power flow algorithms are implemented.

Algorithm	Speed	Result	Convergence	Typical Use Cases	Algorithm call
Newton-Raphson	Medium	Accurate within `error_tolerance`	Quadratic, robust	General purpose, any type of grid	`CalculationMethod.newton_raphson`
Iterative current	Fast (Radial) Slow (Meshed)	Accurate within `error_tolerance`	Linear, less robust	Non-topological change batch calculations like timeseries, radial grids	`CalculationMethod.iterative_current`
Linear	Much Faster	Approximate	Single iteration	Large number of calculations, troubleshooting iterative methods	`CalculationMethod.linear`
Linear current	Much Faster	Approximate	Single iteration	Large number of calculations	`CalculationMethod.linear_current`

Note

By default, the Newton-Raphson method is used.

Note

When all the load/generation types are of constant impedance, the Linear method will be the fastest without loss of accuracy. Therefore power-grid-model will use this method regardless of the input provided by the user in this case.

Quick decision guide for power flow algorithm

For detailed mathematical descriptions of each algorithm, see Power Flow Algorithm Details.

The choice of algorithm depends on your specific requirements for (non)convergence, accuracy, speed, and grid configuration: radial or meshed. Accuracy and convergence should be the first consideration, followed by speed.

Hence if speed is not critical or is a small concern, we recommend using the default Newton-Raphson method for its robustness across all scenarios. If the scenarios are mainly timeseries, you can try Iterative current , this method can improve speed significantly via Matrix prefactorization. There is a possibility you can face non convergence or lower performance compared to the newton raphson method if the network is not radial.

When speed becomes a major concern and desired performance is not achieved with the iterative methods, you can try to explore linear methods. It is recommended to limit the range of loading conditions when using linear methods to avoid unrealistic scenarios where the approximations can give highly inaccurate results.

Overall, these methods are recommended only for a range of possible voltage deviations that are close to 1 p.u. The linear current method will generally give better approximations than the linear method. However at unrealistically high load levels it can give worse approximations than the linear method. Check Power Flow Algorithm Comparison demonstration in Power Flow Algorithm Comparisons to know more about this behavior. A strategy for post calculation verification of results is also provided there. You can identify applicability of linear methods for your use case by experimenting with the Newton-Raphson method to find the range of loading conditions that are relevant for your use case and then only use linear methods within this range for the specific grid configuration.

Non convergence of newton raphson is a good signal of unpractical or unfeasible systems. This signal can be ignored when using linear methods. Similarly, having atleast some results from linear methods can aid in finding data errors or the reason for non convergence of newton raphson method.

Regulated power flow calculations

Regulated power flow calculations are disabled by default.

At the time of writing, the following regulated power flow calculation types are implemented. Please refer to their respective sections for detailed documentation.

Regulation type	Setting	Enum values
Automatic tap changing	`tap_changing_strategy`	`TapChangingStrategy`

Power flow with automatic tap changing

Some of the most important regulators in the grid affect the tap position of transformers. These Transformer Tap Regulators try to regulate a control voltage \(U_{\text{control}}\) such that it is within a specified voltage band. The \(U_{\text{control}}\) may be compensated for the voltage drop during transport. Power flow calculations that take the behavior of these regulators into account may be toggled by providing one of the following strategies to the tap_changing_strategy option.

Algorithm	Default	Speed	Algorithm call
No automatic tap changing (regular power flow)	✔	✔	`TapChangingStrategy.disabled`
Optimize tap positions for any value in the voltage band			`TapChangingStrategy.any_valid_tap`
Optimize tap positions for lowest possible voltage in the voltage band			`TapChangingStrategy.min_voltage_tap`
Optimize tap positions for lowest possible voltage in the voltage band			`TapChangingStrategy.max_voltage_tap`
Optimize tap positions for any value in the voltage band with binary search		✔	`TapChangingStrategy.fast_any_tap`

For detailed control logic, initialization behavior, search methods, and error handling for automatic tap changing, see Automatic Tap Changing Algorithm Details.

State estimation algorithms

Weighted least squares (WLS) state estimation can be performed with power-grid-model to evaluate the state variable with the highest likelihood given (pseudo) measurement input.

At the moment, the following state estimation algorithms are implemented.

Algorithm	Default	Speed	Accuracy	Algorithm call
Iterative linear	✔	✔		`CalculationMethod.iterative_linear`
Newton-Raphson			✔	`CalculationMethod.newton_raphson`

Note

By default, the Iterative linear method is used.

For detailed mathematical descriptions including the WLS formulation, measurement aggregation, sensor transformations, and each algorithm, see State Estimation Algorithm Details.

Short circuit calculation algorithms

In the short circuit calculation, specific equations are solved with border conditions of faults added as constraints to determine the initial symmetrical short circuit current for a fault, which is then used to derive further calculations of short circuit studies applications.

At the moment, the following short circuit algorithms are implemented.

Algorithm	Default	Speed	Accuracy	Algorithm call
IEC 60909	✔	✔		`CalculationMethod.iec60909`

For detailed mathematical descriptions including the short circuit equations and IEC 60909 implementation details, see Short Circuit Algorithm Details.

Batch Calculations

Usually, a single power-flow or state estimation calculation would not be enough to get insights in the grid. Any form of multiple calculations can be carried out in power-grid-model using batch calculations. Batches are not restricted to any particular type of calculations, like timeseries or contingency analysis or their combination. They can be used for determining hosting/loading capacity, determining optimal tap positions, estimating system losses, monte-carlo simulations or any other form of multiple calculations required in a power-flow study. The framework for creating the batches is the same for all types of calculations. For every component, the attributes that can be updated in a batch scenario are mentioned in Components. Examples of batch calculations for timeseries and contingency analysis are given in Power Flow Example

The same method as for single calculations, power_grid_model.PowerGridModel.calculate_power_flow, can be used to calculate a number of scenarios in one go. To do this, you need to supply an update_data keyword argument. This keyword argument contains a dictionary of 2D update arrays (one array per component type).

The performance for different batches vary. power-grid-model automatically makes efficient calculations whenever possible. See the Performance Guide for ways to optimally use the performance optimizations.

Batch data set

The parameters of the individual scenarios within a batch can be done by providing deltas compared to the existing state of the model. The values of unchanged attributes and components parameters within a scenario may be implicit (like a delta update) or explicit (similarly to how one would provide a full state). In the context of the power-grid-model, these are called dependent (implicit) and independent (explicit) batch updates, respectively. In both cases, all scenario updates are relative to the state of the model before the call of the calculation. See the examples below for usage.

Dependent batches are useful for a sparse sampling for many different components, e.g. for N-1 checks.
Independent batches are useful for a dense sampling of a small subset of components, e.g. time series power flow calculation.

See the Performance Guide for more suggestions.

Example: dependent batch update

# 3 scenarios, 3 objects (lines)
# for each scenario, only one line is specified
line_update = initialize_array(DatasetType.update, ComponentType.line, (3, 1))

# set the mutations for each scenario: disable one of the three lines
for component_update, component_id in zip(line_update, (3, 5, 8)):
    component_update[AttributeType.id] = component_id
    component_update[AttributeType.from_status] = 0
    component_update[AttributeType.to_status] = 0

non_independent_update_data = {ComponentType.line: line_update}

Example: full batch update data

# 3 scenarios, 3 objects (lines)
# for each scenario, all lines are specified
line_update = initialize_array(DatasetType.update, ComponentType.line, (3, 3))

# use broadcasting to specify the default state
line_update[AttributeType.id] = [[3, 5, 8]]
line_update[AttributeType.from_status] = 1
line_update[AttributeType.to_status] = 1

# set the mutations for each scenario: disable one of the three lines
for component_idx, scenario in enumerate(line_update):
    component = scenario[component_idx]
    component[AttributeType.from_status] = 0
    component[AttributeType.to_status] = 0

independent_update_data = {ComponentType.line: line_update}

Cartesian product of Batch Datasets

Consider an example of running a contingency analysis with a timeseries data. Or maybe probablistic data along with timeseries data. In such simulations, it is required to perform a loadflow on a cartesian product of situations. This is possible to do via providing the update_data with a list of multiple batch datasets. ie. a list[BatchDataset] The datasets can be of row based or columnar format. The output of such calculation would be flattened with dimension \(scenarios * components\).

Example: Cartesian product of datasets

# 5 scenarios of timeseries
load_update = initialize_array(DatasetType.update, ComponentType.sym_load, (5, 1))
# (Fill load_update)
line_update = initialize_array(DatasetType.update, ComponentType.line, (3, 1))
# (Fill line_update)

product_update_data = [{ComponentType.line: load_update}, {ComponentType.sym_load: line_udpate }]

Parallel Computing

The batch calculation supports shared memory multi-threading parallel computing. The common internal states and variables are shared as much as possible to save memory usage and avoid copy.

You can set the threading keyword argument in the calculate_* functions (like calculate_power_flow()) to enable/disable parallel computing.

threading=-1, use sequential computing (default)
threading=0, use number of threads available from the machine hardware (recommended)
threading>0, set the number of threads you want to use