Available powerflow algorithms
The documentation of this section is in progress. It is rather incomplete for the moment, and only exposes the most basic features.
If you are interested in collaborating to improve this section, let us know.
See also
Naming conventions: “solver” vs “algorithm” — explains the three distinct meanings of “solver” in lightsim2grid,
how the AlgorithmType enum values are named, and the migration
table from old names (KLU, SparseLU, DC, …) to the new canonical names.
Types of powerflow algorithms
LightSim2Grid supports four families of powerflow algorithms:
Gauss-Seidel:
lightsim2grid.algorithm.GaussSeidelAlgoandlightsim2grid.algorithm.GaussSeidelSynchAlgo. Solve the AC powerflow using the iterative Gauss-Seidel method (see gausspf in MATPOWER).DC approximation: solve the linearised (DC) power-flow equations using a direct sparse factorisation. Up to four linear-solver backends are available:
lightsim2grid.algorithm.DC_SparseLU— Eigen SparseLU (always available)lightsim2grid.algorithm.DC_KLU— SuiteSparse KLU (when compiled with KLU)lightsim2grid.algorithm.DC_NICSLU— NICSLU (requires license + source build)lightsim2grid.algorithm.DC_CKTSO— CKTSO (requires license + source build)
Newton-Raphson (single slack): solves the full AC equations with a single slack bus. If multiple slack buses are present only the first is used; the others are treated as PV buses. Available with four linear-solver backends:
lightsim2grid.algorithm.NRSing_SparseLUlightsim2grid.algorithm.NRSing_KLUlightsim2grid.algorithm.NRSing_NICSLUlightsim2grid.algorithm.NRSing_CKTSO
Newton-Raphson (distributed / multi-slack): solves the full AC equations with multiple slack buses. Available with four linear-solver backends:
lightsim2grid.algorithm.NR_SparseLUlightsim2grid.algorithm.NR_KLUlightsim2grid.algorithm.NR_NICSLUlightsim2grid.algorithm.NR_CKTSO
Fast-Decoupled Powerflow (FDPF): the XB and BX variants of the fast-decoupled Newton-Raphson method. Available with four linear-solver backends each:
lightsim2grid.algorithm.FDPF_XB_SparseLU,lightsim2grid.algorithm.FDPF_BX_SparseLUlightsim2grid.algorithm.FDPF_XB_KLU,lightsim2grid.algorithm.FDPF_BX_KLUlightsim2grid.algorithm.FDPF_XB_NICSLU,lightsim2grid.algorithm.FDPF_BX_NICSLUlightsim2grid.algorithm.FDPF_XB_CKTSO,lightsim2grid.algorithm.FDPF_BX_CKTSO
Warning
Algorithms based on NICSLU and CKTSO require a compilation from source.
CKTSO algorithms are (for now) only tested on Linux.
Default algorithm selection
By default, when KLU is available, lightsim2grid uses:
NR_KLU(AC multi-slack)NRSing_KLU(AC single-slack, when only one slack bus is detected)DC_KLU(DC approximation)
When KLU is not available (e.g. installed from PyPI without a source build), it falls back to:
NR_SparseLUNRSing_SparseLUDC_SparseLU
Correspondence between class and AlgorithmType enum
Python class |
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Usage
The preferred way to select an algorithm is to pass algo_type when creating the backend:
import grid2op
import lightsim2grid
from lightsim2grid import LightSimBackend
from lightsim2grid.algorithm import AlgorithmType
env_name = "l2rpn_case14_sandbox"
env = grid2op.make(env_name,
backend=LightSimBackend(algo_type=AlgorithmType.NR_KLU))
You can also change the algorithm after creation (not recommended, but supported):
import grid2op
import lightsim2grid
from lightsim2grid import LightSimBackend
from lightsim2grid.algorithm import AlgorithmType
env_name = "l2rpn_case14_sandbox"
env = grid2op.make(env_name, backend=LightSimBackend())
# switch to Gauss-Seidel
env.backend._grid.change_algorithm(AlgorithmType.GaussSeidel)
# inspect which algorithms are available in this build
print(env.backend._grid.available_algorithm_names())
# tune solver parameters
env.backend.set_solver_max_iter(10000)
env.backend.set_tol(1e-7)
env.reset() # apply the change
Note
For the complete list of available algorithm types, see lightsim2grid.algorithm.AlgorithmType.
For an explanation of the naming convention and the three distinct meanings of “solver”, see
Naming conventions: “solver” vs “algorithm”.