The ExaData artifact contains test cases relevant to the Exascale Computing Project. It is built from the git repository available at ExaData. Apart from the standard MATPOWER files it additionally contains demand scenarios and contingencies used in multiperiod security constrained optimal power flow settings.
Settings
This document was generated with Documenter.jl version 1.0.1 on Monday 25 September 2023. Using Julia version 1.9.3.
The ExaData artifact contains test cases relevant to the Exascale Computing Project. It is built from the git repository available at ExaData. Apart from the standard MATPOWER files it additionally contains demand scenarios and contingencies used in multiperiod security constrained optimal power flow settings.
Settings
This document was generated with Documenter.jl version 1.0.1 on Wednesday 27 September 2023. Using Julia version 1.9.3.
ExaPF.jl is a package to solve the power flow problem on upcoming exascale architectures. The code has been designed to be:
ExaPF implements a vectorized modeler for power systems, which allows to manipulate basic expressions. All expressions are fully differentiable : their first and second-order derivatives can be extracted efficiently using automatic differentiation. In addition, we leverage the packages CUDA.jl and KernelAbstractions.jl to make ExaPF portable across GPU architectures.
This research was supported by the Exascale Computing Project (17-SC-20-SC), a joint project of the U.S. Department of Energy’s Office of Science and National Nuclear Security Administration, responsible for delivering a capable exascale ecosystem, including software, applications, and hardware technology, to support the nation’s exascale computing imperative.
Settings
This document was generated with Documenter.jl version 1.0.1 on Monday 25 September 2023. Using Julia version 1.9.3.
ExaPF.jl is a package to solve the power flow problem on upcoming exascale architectures. The code has been designed to be:
ExaPF implements a vectorized modeler for power systems, which allows to manipulate basic expressions. All expressions are fully differentiable : their first and second-order derivatives can be extracted efficiently using automatic differentiation. In addition, we leverage the packages CUDA.jl and KernelAbstractions.jl to make ExaPF portable across GPU architectures.
This research was supported by the Exascale Computing Project (17-SC-20-SC), a joint project of the U.S. Department of Energy’s Office of Science and National Nuclear Security Administration, responsible for delivering a capable exascale ecosystem, including software, applications, and hardware technology, to support the nation’s exascale computing imperative.
Settings
This document was generated with Documenter.jl version 1.0.1 on Wednesday 27 September 2023. Using Julia version 1.9.3.
ExaPF.AutoDiff.AbstractStack — TypeAbstractStack{VT}Abstract variable storing the inputs and the intermediate values in the expression tree.
ExaPF.AutoDiff.AbstractExpression — TypeAbstractExpressionAbstract type for differentiable function $f(x)$. Any AbstractExpression implements two functions: a forward mode to evaluate $f(x)$, and an adjoint to evaluate $∂f(x)$.
Forward mode
The direct evaluation of the function $f$ is implemented as
(expr::AbstractExpression)(output::VT, stack::AbstractStack{VT}) where VT<:AbstractArray
+AutoDiff · ExaPF.jl AutoDiff
Variables
ExaPF.AutoDiff.AbstractStack — TypeAbstractStack{VT}
Abstract variable storing the inputs and the intermediate values in the expression tree.
sourceExpressions
ExaPF.AutoDiff.AbstractExpression — TypeAbstractExpression
Abstract type for differentiable function $f(x)$. Any AbstractExpression implements two functions: a forward mode to evaluate $f(x)$, and an adjoint to evaluate $∂f(x)$.
Forward mode
The direct evaluation of the function $f$ is implemented as
(expr::AbstractExpression)(output::VT, stack::AbstractStack{VT}) where VT<:AbstractArray
the input being specified in stack, the results being stored in the array output.
Reverse mode
The adjoint of the function is specified by the function adjoint!, with the signature:
adjoint!(expr::AbstractExpression, ∂stack::AbstractStack{VT}, stack::AbstractStack{VT}, ̄v::VT) where VT<:AbstractArray
-
The variable stack stores the result of the direct evaluation, and is not modified in adjoint!. The results are stored inside the adjoint stack ∂stack.
sourceExaPF.AutoDiff.adjoint! — Functionadjoint!(expr::AbstractExpression, ∂stack::AbstractStack{VT}, stack::AbstractStack{VT}, ̄v::VT) where VT<:AbstractArray
Compute the adjoint of the AbstractExpression expr with relation to the adjoint vector ̄v. The results are stored in the adjoint stack ∂stack. The variable stack stores the result of a previous direct evaluation, and is not modified in adjoint!.
sourceFirst and second-order derivatives
ExaPF.AutoDiff.AbstractJacobian — TypeAbstractJacobian
Automatic differentiation for the compressed Jacobian of any nonlinear constraint $h(x)$.
sourceExaPF.AutoDiff.AbstractHessianProd — TypeAbstractHessianProd
Returns the adjoint-Hessian-vector product $λ^⊤ H v$ of any nonlinear constraint $h(x)$.
sourceExaPF.AutoDiff.AbstractFullHessian — TypeAbstractHessianProd
Full sparse Hessian $H$ of any nonlinear constraint $h(x)$.
sourceUtils
ExaPF.AutoDiff.seed! — Functionseed!(
+
The variable stack stores the result of the direct evaluation, and is not modified in adjoint!. The results are stored inside the adjoint stack ∂stack.
sourceExaPF.AutoDiff.adjoint! — Functionadjoint!(expr::AbstractExpression, ∂stack::AbstractStack{VT}, stack::AbstractStack{VT}, ̄v::VT) where VT<:AbstractArray
Compute the adjoint of the AbstractExpression expr with relation to the adjoint vector ̄v. The results are stored in the adjoint stack ∂stack. The variable stack stores the result of a previous direct evaluation, and is not modified in adjoint!.
sourceFirst and second-order derivatives
ExaPF.AutoDiff.AbstractJacobian — TypeAbstractJacobian
Automatic differentiation for the compressed Jacobian of any nonlinear constraint $h(x)$.
sourceExaPF.AutoDiff.AbstractHessianProd — TypeAbstractHessianProd
Returns the adjoint-Hessian-vector product $λ^⊤ H v$ of any nonlinear constraint $h(x)$.
sourceExaPF.AutoDiff.AbstractFullHessian — TypeAbstractHessianProd
Full sparse Hessian $H$ of any nonlinear constraint $h(x)$.
sourceUtils
ExaPF.AutoDiff.seed! — Functionseed!(
H::AbstractHessianProd,
v::AbstractVector{T},
-) where {T}
Seed the duals with v to compute the Hessian vector product $λ^⊤ H v$.
sourceExaPF.AutoDiff.seed_coloring! — Functionseed_coloring!(
+) where {T}
Seed the duals with v to compute the Hessian vector product $λ^⊤ H v$.
sourceExaPF.AutoDiff.seed_coloring! — Functionseed_coloring!(
M::Union{AbstractJacobian, AbstractFullHessian}
coloring::AbstractVector,
-)
Seed the duals with the coloring based seeds to compute the Jacobian or Hessian $M$.
sourceExaPF.AutoDiff.partials! — Functionpartials!(jac::AbstractJacobian)
Extract partials from Jacobian jac in jac.J.
sourcepartials!(hess::AbstractFullHessian)
Extract partials from Hessian hess into hess.H.
sourceExaPF.AutoDiff.set_value! — Functionset_value!(
+)
Seed the duals with the coloring based seeds to compute the Jacobian or Hessian $M$.
sourceExaPF.AutoDiff.partials! — Functionpartials!(jac::AbstractJacobian)
Extract partials from Jacobian jac in jac.J.
sourcepartials!(hess::AbstractFullHessian)
Extract partials from Hessian hess into hess.H.
sourceExaPF.AutoDiff.set_value! — Functionset_value!(
jac,
primals::AbstractVector{T}
-) where {T}
Set values of ForwardDiff.Dual numbers in jac to primals.
sourceSettings
This document was generated with Documenter.jl version 1.0.1 on Monday 25 September 2023. Using Julia version 1.9.3.
Set values of ForwardDiff.Dual numbers in jac to primals.
Settings
This document was generated with Documenter.jl version 1.0.1 on Wednesday 27 September 2023. Using Julia version 1.9.3.
ExaPF.AbstractVariable — TypeAbstractVariableVariables corresponding to a particular formulation.
ExaPF.AbstractFormulation — TypeAbstractFormulationInterface between the data and the mathemical formulation.
ExaPF.State — TypeState <: AbstractVariableAll variables $x$ depending on the variables Control $u$ through the non-linear equation $g(x, u) = 0$.
ExaPF.Control — TypeControl <: AbstractVariableIndependent variables $u$ used in the reduced-space formulation.
ExaPF.PolarForm — TypePolarForm{T, IT, VT, MT} <: AbstractPolarFormulationImplement the polar formulation associated to the network's equations.
Wrap a PS.PowerNetwork network to load the data on the target device (CPU() and CUDABackend() are currently supported).
Example
julia> const PS = ExaPF.PowerSystem;
+Polar formulation · ExaPF.jl Polar formulation
Generic templates
ExaPF.AbstractVariable — TypeAbstractVariable
Variables corresponding to a particular formulation.
sourceExaPF.AbstractFormulation — TypeAbstractFormulation
Interface between the data and the mathemical formulation.
sourceExaPF.State — TypeState <: AbstractVariable
All variables $x$ depending on the variables Control $u$ through the non-linear equation $g(x, u) = 0$.
sourceExaPF.Control — TypeControl <: AbstractVariable
Independent variables $u$ used in the reduced-space formulation.
sourceStructure and variables
ExaPF.PolarForm — TypePolarForm{T, IT, VT, MT} <: AbstractPolarFormulation
Implement the polar formulation associated to the network's equations.
Wrap a PS.PowerNetwork network to load the data on the target device (CPU() and CUDABackend() are currently supported).
Example
julia> const PS = ExaPF.PowerSystem;
julia> network_data = PS.load_case("case9.m");
@@ -12,7 +12,7 @@
giving a mathematical formulation with:
#controls: 5
#states : 14
-
sourceExaPF.BlockPolarForm — TypeBlockPolarForm{T, IT, VT, MT} <: AbstractFormulation
Block polar formulation: duplicates k different polar models to evaluate them in parallel.
sourceExaPF.load_polar — Functionload_polar(case, device=CPU(); dir=PS.EXADATA)
Load a PolarForm instance from the specified benchmark library dir on the target device (default is CPU). ExaPF uses two different benchmark libraries: MATPOWER (dir=EXADATA) and PGLIB-OPF (dir=PGLIB).
Examples
julia> polar = ExaPF.load_polar("case9")
+
sourceExaPF.BlockPolarForm — TypeBlockPolarForm{T, IT, VT, MT} <: AbstractFormulation
Block polar formulation: duplicates k different polar models to evaluate them in parallel.
sourceExaPF.load_polar — Functionload_polar(case, device=CPU(); dir=PS.EXADATA)
Load a PolarForm instance from the specified benchmark library dir on the target device (default is CPU). ExaPF uses two different benchmark libraries: MATPOWER (dir=EXADATA) and PGLIB-OPF (dir=PGLIB).
Examples
julia> polar = ExaPF.load_polar("case9")
Polar formulation (instantiated on device CPU(false))
Network characteristics:
#buses: 9 (#slack: 1 #PV: 2 #PQ: 6)
@@ -21,7 +21,7 @@
giving a mathematical formulation with:
#controls: 5
#states : 14
-
sourceExaPF.NetworkStack — TypeNetworkStack{VT,VD,MT} <: AbstractNetworkStack{VT}
+
sourceExaPF.NetworkStack — TypeNetworkStack{VT,VD,MT} <: AbstractNetworkStack{VT}
NetworkStack(polar::PolarForm)
NetworkStack(nbus::Int, ngen::Int, nlines::Int, VT::Type)
Store the variables associated to the polar formulation. The variables are stored in the field input, ordered as follows
input = [vmag ; vang ; pgen]
The object stores also intermediate variables needed in the expression tree, such as the LKMR basis ψ.
Notes
The NetworkStack can be instantiated on the host or on the target device.
Examples
julia> polar = ExaPF.load_polar("case9");
@@ -39,7 +39,7 @@
1.0
1.0
1.0
-
sourceExaPF.init! — Functioninit!(polar::PolarForm, stack::NetworkStack)
Set stack.input with the initial values specified in the base PS.PowerNetwork object.
sourceThe state and the control are defined as mapping:
ExaPF.mapping — Functionmapping(polar::PolarForm, ::Control)
Return the mapping associated to the Control() in NetworkStack according to the polar formulation PolarForm.
Examples
julia> polar = ExaPF.load_polar("case9");
+
sourceExaPF.init! — Functioninit!(polar::PolarForm, stack::NetworkStack)
Set stack.input with the initial values specified in the base PS.PowerNetwork object.
sourceThe state and the control are defined as mapping:
ExaPF.mapping — Functionmapping(polar::PolarForm, ::Control)
Return the mapping associated to the Control() in NetworkStack according to the polar formulation PolarForm.
Examples
julia> polar = ExaPF.load_polar("case9");
julia> mapu = ExaPF.mapping(polar, Control())
5-element Vector{Int64}:
@@ -48,7 +48,7 @@
3
20
21
-
sourcemapping(polar::PolarForm, ::State)
Return the mapping associated to the State() in NetworkStack according to the polar formulation PolarForm.
Examples
julia> polar = ExaPF.load_polar("case9");
+
sourcemapping(polar::PolarForm, ::State)
Return the mapping associated to the State() in NetworkStack according to the polar formulation PolarForm.
Examples
julia> polar = ExaPF.load_polar("case9");
julia> mapu = ExaPF.mapping(polar, State())
14-element Vector{Int64}:
@@ -66,7 +66,7 @@
7
8
9
-
sourcePowerflow solver
ExaPF.run_pf — Functionrun_pf(
+
sourcePowerflow solver
ExaPF.run_pf — Functionrun_pf(
polar::PolarForm, stack::NetworkStack;
rtol=1e-8, max_iter=20, verbose=0,
)
Solve the power flow equations $g(x, u) = 0$ w.r.t. the stack $x$, using the (NewtonRaphson algorithm. The initial state $x$ is specified implicitly inside stack, with the mapping mapping associated to the polar formulation. The object stack is modified inplace in the function.
The algorithm stops when a tolerance rtol or a maximum number of iterations maxiter is reached.
Arguments
polar::AbstractFormulation: formulation of the power flow equationstack::NetworkStack: initial values in the network
Examples
julia> polar = ExaPF.load_polar("case9");
@@ -79,7 +79,7 @@
true
julia> conv.n_iterations
-4
sourceExaPF.nlsolve! — Functionnlsolve!(
+4
sourceExaPF.nlsolve! — Functionnlsolve!(
algo::NewtonRaphson,
jac::Jacobian,
stack::NetworkStack;
@@ -100,7 +100,7 @@
true
julia> conv.n_iterations
-4
sourceExaPF.NewtonRaphson — TypeNewtonRaphson <: AbstractNonLinearSolver
Newton-Raphson algorithm.
Attributes
maxiter::Int (default 20): maximum number of iterationstol::Float64 (default 1e-8): tolerance of the algorithmverbose::Int (default 0): verbosity level
sourceConstraints
The different parts of the polar formulation are implemented in the following AbstractExpression:
ExaPF.PolarBasis — TypePolarBasis{VI, MT} <: AbstractExpression
+4
sourceExaPF.NewtonRaphson — TypeNewtonRaphson <: AbstractNonLinearSolver
Newton-Raphson algorithm.
Attributes
maxiter::Int (default 20): maximum number of iterationstol::Float64 (default 1e-8): tolerance of the algorithmverbose::Int (default 0): verbosity level
sourceConstraints
The different parts of the polar formulation are implemented in the following AbstractExpression:
ExaPF.PolarBasis — TypePolarBasis{VI, MT} <: AbstractExpression
PolarBasis(polar::AbstractPolarFormulation)
Implement the LKMR nonlinear basis. Takes as input the voltage magnitudes vmag and the voltage angles vang and returns
\[ \begin{aligned}
& \psi_\ell^C(v, \theta) = v^f v^t \cos(\theta_f - \theta_t) \quad \forall \ell = 1, \cdots, n_\ell \\
& \psi_\ell^S(v, \theta) = v^f v^t \sin(\theta_f - \theta_t) \quad \forall \ell = 1, \cdots, n_\ell \\
@@ -134,7 +134,7 @@
1.0
1.0
1.0
-
sourceExaPF.PowerFlowBalance — TypePowerFlowBalance{VT, MT}
+
sourceExaPF.PowerFlowBalance — TypePowerFlowBalance{VT, MT}
PowerFlowBalance(polar)
Implement a subset of the power injection corresponding to $(p_{inj}^{pv}, p_{inj}^{pq}, q_{inj}^{pq})$. The function encodes the active balance equations at PV and PQ nodes, and the reactive balance equations at PQ nodes:
\[\begin{aligned}
p_i &= v_i \sum_{j}^{n} v_j (g_{ij}\cos{(\theta_i - \theta_j)} + b_{ij}\sin{(\theta_i - \theta_j})) \,, &
∀ i ∈ \{PV, PQ\} \\
@@ -167,7 +167,7 @@
julia> isapprox(powerflow(stack), zeros(14); atol=1e-8)
true
-
sourceExaPF.VoltageMagnitudeBounds — TypeVoltageMagnitudeBounds
Implement the bounds on voltage magnitudes not taken into account in the bound constraints. In the reduced space, this is associated to the the voltage magnitudes at PQ nodes:
\[v_{pq}^♭ ≤ v_{pq} ≤ v_{pq}^♯ .\]
Dimension: n_pq
Complexity
1 copyto
Note
In the reduced space, the constraints on the voltage magnitudes at PV nodes $v_{pv}$ are taken into account when bounding the control $u$.
Examples
julia> polar = ExaPF.load_polar("case9");
+
sourceExaPF.VoltageMagnitudeBounds — TypeVoltageMagnitudeBounds
Implement the bounds on voltage magnitudes not taken into account in the bound constraints. In the reduced space, this is associated to the the voltage magnitudes at PQ nodes:
\[v_{pq}^♭ ≤ v_{pq} ≤ v_{pq}^♯ .\]
Dimension: n_pq
Complexity
1 copyto
Note
In the reduced space, the constraints on the voltage magnitudes at PV nodes $v_{pv}$ are taken into account when bounding the control $u$.
Examples
julia> polar = ExaPF.load_polar("case9");
julia> stack = ExaPF.NetworkStack(polar);
@@ -181,7 +181,7 @@
1.0
1.0
1.0
-
sourceExaPF.PowerGenerationBounds — TypePowerGenerationBounds{VT, MT}
+
sourceExaPF.PowerGenerationBounds — TypePowerGenerationBounds{VT, MT}
PowerGenerationBounds(polar)
Constraints on the active power productions and on the reactive power productions that are not already taken into account in the bound constraints. In the reduced space, that amounts to
\[p_{g,ref}^♭ ≤ p_{g,ref} ≤ p_{g,ref}^♯ ;
C_g q_g^♭ ≤ C_g q_g ≤ C_g q_g^♯ .\]
Require composition with PolarBasis.
Dimension: n_pv + 2 n_ref
Complexity
1 copyto, 1 SpMV
Examples
julia> polar = ExaPF.load_polar("case9");
@@ -197,7 +197,7 @@
0.24069
0.144601
-0.03649
-
sourceExaPF.LineFlows — TypeLineFlows{VT, MT}
+
sourceExaPF.LineFlows — TypeLineFlows{VT, MT}
LineFlows(polar)
Implement thermal limit constraints on the lines of the network.
Require composition with PolarBasis.
Dimension: 2 * n_lines
Complexity
4 SpMV, 4 * n_lines quadratic, 2 * n_lines add
Examples
julia> polar = ExaPF.load_polar("case9");
julia> stack = ExaPF.NetworkStack(polar);
@@ -226,7 +226,7 @@
2.67781
0.726668
0.215497
-
sourceObjective
The production costs is given in the AbstractExpression CostFunction:
ExaPF.CostFunction — TypeCostFunction{VT, MT} <: AutoDiff.AbstractExpression
+
sourceObjective
The production costs is given in the AbstractExpression CostFunction:
ExaPF.CostFunction — TypeCostFunction{VT, MT} <: AutoDiff.AbstractExpression
CostFunction(polar)
Implement the quadratic cost function for OPF
\[ ∑_{g=1}^{n_g} c_{2,g} p_g^2 + c_{1,g} p_g + c_{0,g}\]
Require composition with PolarBasis to evaluate the cost of the reference generator.
Dimension: 1
Complexity
1 SpMV, 1 sum
Examples
julia> polar = ExaPF.load_polar("case9");
julia> stack = ExaPF.NetworkStack(polar);
@@ -236,5 +236,5 @@
julia> cost(stack)
1-element Vector{Float64}:
4509.0275
-
sourceComposition of expressions
The different expressions can be combined together in several different ways.
ExaPF.MultiExpressions — TypeMultiExpressions <: AbstractExpression
Implement expressions concatenation. Takes as input a vector of expressions [expr1,...,exprN] and concatenate them in a single expression mexpr, such that
mexpr(x) = [expr1(x) ; expr2(x) ; ... ; exprN(x)]
-
sourceExaPF.ComposedExpressions — TypeComposedExpressions{Expr1<:PolarBasis, Expr2} <: AbstractExpression
Implement expression composition. Takes as input two expressions expr1 and expr2 and returns a composed expression cexpr such that ``` cexpr(x) = expr2 ∘ expr1(x)
Notes
Currently, only PolarBasis is supported for expr1.
sourceSettings
This document was generated with Documenter.jl version 1.0.1 on Monday 25 September 2023. Using Julia version 1.9.3.
The different expressions can be combined together in several different ways.
ExaPF.MultiExpressions — TypeMultiExpressions <: AbstractExpressionImplement expressions concatenation. Takes as input a vector of expressions [expr1,...,exprN] and concatenate them in a single expression mexpr, such that
mexpr(x) = [expr1(x) ; expr2(x) ; ... ; exprN(x)]
+ExaPF.ComposedExpressions — TypeComposedExpressions{Expr1<:PolarBasis, Expr2} <: AbstractExpressionImplement expression composition. Takes as input two expressions expr1 and expr2 and returns a composed expression cexpr such that ``` cexpr(x) = expr2 ∘ expr1(x)
Notes
Currently, only PolarBasis is supported for expr1.
Settings
This document was generated with Documenter.jl version 1.0.1 on Wednesday 27 September 2023. Using Julia version 1.9.3.
ExaPF allows to solve linear systems with either direct and indirect linear algebra, both on CPU and on GPU. To solve a linear system $Ax = b$, ExaPF uses the function ldiv!.
LinearAlgebra.ldiv! — Functionldiv!(solver, x, A, y)
-ldiv!(solver, x, y)solver::AbstractLinearSolver: linear solver to solve the systemx::AbstractVector: SolutionA::AbstractMatrix: Input matrixy::AbstractVector: RHSSolve the linear system $A x = y$ using the algorithm specified in solver. If A is not specified, the function will used directly the factorization stored inside solver.
ExaPF wraps UMFPACK (shipped with SuiteSparse.jl) on the CPU, and CUSPARSE on CUDA device.
ExaPF.LinearSolvers.DirectSolver — TypeDirectSolver <: AbstractLinearSolverSolve linear system $A x = y$ with direct linear algebra.
DirectSolver uses UMFPACK to solve the linear systemDirectSolver redirects the resolution to the method CUSOLVER.csrlsvqrExaPF.LinearSolvers.KrylovBICGSTAB — TypeKrylovBICGSTAB <: AbstractIterativeLinearSolver
-KrylovBICGSTAB(precond; verbose=0, rtol=1e-10, atol=1e-10)Wrap Krylov.jl's BICGSTAB algorithm to solve iteratively the linear system $A x = y$.
ExaPF.LinearSolvers.DQGMRES — TypeDQGMRES <: AbstractIterativeLinearSolver
-DQGMRES(precond; verbose=false, memory=4)Wrap Krylov.jl's DQGMRES algorithm to solve iteratively the linear system $A x = y$.
ExaPF.LinearSolvers.BICGSTAB — TypeBICGSTAB <: AbstractIterativeLinearSolver
-BICGSTAB(precond; maxiter=2_000, tol=1e-8, verbose=false)Custom BICGSTAB implementation to solve iteratively the linear system $A x = y$.
ExaPF.LinearSolvers.EigenBICGSTAB — TypeEigenBICGSTAB <: AbstractIterativeLinearSolver
-EigenBICGSTAB(precond; maxiter=2_000, tol=1e-8, verbose=false)Julia's port of Eigen's BICGSTAB to solve iteratively the linear system $A x = y$.
ExaPF.jl is shipped with a custom BICGSTAB implementation. However, we highly recommend to use KrylovBICGSTAB instead, which has proved to be more robust.
ExaPF.LinearSolvers.bicgstab — Functionbicgstab(A, b, P, xi;
+ldiv!(solver, x, y)solver::AbstractLinearSolver: linear solver to solve the systemx::AbstractVector: SolutionA::AbstractMatrix: Input matrixy::AbstractVector: RHSSolve the linear system $A x = y$ using the algorithm specified in solver. If A is not specified, the function will used directly the factorization stored inside solver.
ExaPF wraps UMFPACK (shipped with SuiteSparse.jl) on the CPU, and CUSPARSE on CUDA device.
ExaPF.LinearSolvers.DirectSolver — TypeDirectSolver <: AbstractLinearSolverSolve linear system $A x = y$ with direct linear algebra.
DirectSolver uses UMFPACK to solve the linear systemDirectSolver redirects the resolution to the method CUSOLVER.csrlsvqrExaPF.LinearSolvers.KrylovBICGSTAB — TypeKrylovBICGSTAB <: AbstractIterativeLinearSolver
+KrylovBICGSTAB(precond; verbose=0, rtol=1e-10, atol=1e-10)Wrap Krylov.jl's BICGSTAB algorithm to solve iteratively the linear system $A x = y$.
ExaPF.LinearSolvers.DQGMRES — TypeDQGMRES <: AbstractIterativeLinearSolver
+DQGMRES(precond; verbose=false, memory=4)Wrap Krylov.jl's DQGMRES algorithm to solve iteratively the linear system $A x = y$.
ExaPF.LinearSolvers.BICGSTAB — TypeBICGSTAB <: AbstractIterativeLinearSolver
+BICGSTAB(precond; maxiter=2_000, tol=1e-8, verbose=false)Custom BICGSTAB implementation to solve iteratively the linear system $A x = y$.
ExaPF.LinearSolvers.EigenBICGSTAB — TypeEigenBICGSTAB <: AbstractIterativeLinearSolver
+EigenBICGSTAB(precond; maxiter=2_000, tol=1e-8, verbose=false)Julia's port of Eigen's BICGSTAB to solve iteratively the linear system $A x = y$.
ExaPF.jl is shipped with a custom BICGSTAB implementation. However, we highly recommend to use KrylovBICGSTAB instead, which has proved to be more robust.
ExaPF.LinearSolvers.bicgstab — Functionbicgstab(A, b, P, xi;
tol=1e-8,
maxiter=size(A, 1),
verbose=false,
- maxtol=1e20)BiCGSTAB implementation according to
Van der Vorst, Henk A. "Bi-CGSTAB: A fast and smoothly converging variant of Bi-CG for the solution of nonsymmetric linear systems." SIAM Journal on scientific and Statistical Computing 13, no. 2 (1992): 631-644.
Available linear solvers can be queried with
ExaPF.LinearSolvers.list_solvers — Functionlist_solvers(::KernelAbstractions.Device)List linear solvers available on current device.
To solve linear systems with iterative methods, ExaPF provides an implementation of a block-Jacobi preconditioner, portable on GPU.
ExaPF.LinearSolvers.AbstractPreconditioner — TypeAbstractPreconditionerPreconditioners for the iterative solvers mostly focused on GPUs
ExaPF.LinearSolvers.BlockJacobiPreconditioner — TypeBlockJacobiPreconditionerOverlapping-Schwarz preconditioner.
Attributes
nblocks::Int64: Number of partitions or blocks.blocksize::Int64: Size of each block.partitions::Vector{Vector{Int64}}:npart` partitions stored as listscupartitions: partitions transfered to the GPUlpartitions::Vector{Int64}`: Length of each partitions.culpartitions::Vector{Int64}`: Length of each partitions, on the GPU.blocks: Dense blocks of the block-Jacobicublocks: Js transfered to the GPUmap: The partitions as a mapping to construct viewscumap: cumap transferred to the GPU`part: Partitioning as output by Metiscupart: part transferred to the GPUExaPF.LinearSolvers.update — Functionfunction update(J::CuSparseMatrixCSR, p)Update the preconditioner p from the sparse Jacobian J in CSR format for the GPU
cuJs are filled from the sparse Jacobian Jp.P from the dense blocks cuJsfunction update(J::SparseMatrixCSC, p)Update the preconditioner p from the sparse Jacobian J in CSC format for the CPU
Note that this implements the same algorithm as for the GPU and becomes very slow on CPU with growing number of blocks.
Settings
This document was generated with Documenter.jl version 1.0.1 on Monday 25 September 2023. Using Julia version 1.9.3.
BiCGSTAB implementation according to
sourceVan der Vorst, Henk A. "Bi-CGSTAB: A fast and smoothly converging variant of Bi-CG for the solution of nonsymmetric linear systems." SIAM Journal on scientific and Statistical Computing 13, no. 2 (1992): 631-644.
Available linear solvers can be queried with
ExaPF.LinearSolvers.list_solvers — Functionlist_solvers(::KernelAbstractions.Device)List linear solvers available on current device.
To solve linear systems with iterative methods, ExaPF provides an implementation of a block-Jacobi preconditioner, portable on GPU.
ExaPF.LinearSolvers.AbstractPreconditioner — TypeAbstractPreconditionerPreconditioners for the iterative solvers mostly focused on GPUs
ExaPF.LinearSolvers.BlockJacobiPreconditioner — TypeBlockJacobiPreconditionerOverlapping-Schwarz preconditioner.
Attributes
nblocks::Int64: Number of partitions or blocks.blocksize::Int64: Size of each block.partitions::Vector{Vector{Int64}}:npart` partitions stored as listscupartitions: partitions transfered to the GPUlpartitions::Vector{Int64}`: Length of each partitions.culpartitions::Vector{Int64}`: Length of each partitions, on the GPU.blocks: Dense blocks of the block-Jacobicublocks: Js transfered to the GPUmap: The partitions as a mapping to construct viewscumap: cumap transferred to the GPU`part: Partitioning as output by Metiscupart: part transferred to the GPUExaPF.LinearSolvers.update — Functionfunction update(J::CuSparseMatrixCSR, p)Update the preconditioner p from the sparse Jacobian J in CSR format for the GPU
cuJs are filled from the sparse Jacobian Jp.P from the dense blocks cuJsfunction update(J::SparseMatrixCSC, p)Update the preconditioner p from the sparse Jacobian J in CSC format for the CPU
Note that this implements the same algorithm as for the GPU and becomes very slow on CPU with growing number of blocks.
Settings
This document was generated with Documenter.jl version 1.0.1 on Wednesday 27 September 2023. Using Julia version 1.9.3.