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.2.1 on Tuesday 5 December 2023. Using Julia version 1.9.4.
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.2.1 on Thursday 7 December 2023. Using Julia version 1.9.4.
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 provide extensions that leverage the packages CUDA.jl, [AMDGPU.jl]((https://github.com/JuliaGPU/AMDGPU.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.2.1 on Tuesday 5 December 2023. Using Julia version 1.9.4.
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 provide extensions that leverage the packages CUDA.jl, [AMDGPU.jl]((https://github.com/JuliaGPU/AMDGPU.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.2.1 on Thursday 7 December 2023. Using Julia version 1.9.4.
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.2.1 on Tuesday 5 December 2023. Using Julia version 1.9.4.
Set values of ForwardDiff.Dual numbers in jac to primals.
Settings
This document was generated with Documenter.jl version 1.2.1 on Thursday 7 December 2023. Using Julia version 1.9.4.
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.2.1 on Tuesday 5 December 2023. Using Julia version 1.9.4.
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.2.1 on Thursday 7 December 2023. Using Julia version 1.9.4.
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!.
ExaPF.LinearSolvers.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.Bicgstab — TypeBicgstab <: AbstractIterativeLinearSolver
-Bicgstab(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$.
Available linear solvers can be queried with
ExaPF.LinearSolvers.list_solvers — Functionlist_solvers(::KernelAbstractions.Device)List linear solvers available on current device.
A default solver is provided for each vendor backend.
ExaPF.LinearSolvers.default_linear_solver — Functiondefault_linear_solver(A, ::KA.CPU)Default linear solver on the CPU.
ExaPF.jl provides an implementation of block-GMRES to solve linear systems with multiple righ-hand sides.
ExaPF.LinearSolvers.BlockKrylovSolver — TypeAbstract type for using block Krylov solvers in-place
ExaPF.LinearSolvers.BlockGmresSolver — TypeType for storing the vectors required by the in-place version of BLOCK-GMRES.
The outer constructors
solver = BlockGmresSolver(m, n, p, memory, SV, SM)
-solver = BlockGmresSolver(A, B; memory=5)may be used in order to create these vectors. memory is set to div(n,p) if the value given is larger than div(n,p).
ExaPF.LinearSolvers.block_gmres — Function(X, stats) = block_gmres(A, B; X0::AbstractMatrix{FC}; memory::Int=20, M=I, N=I,
+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.Bicgstab — TypeBicgstab <: AbstractIterativeLinearSolver
+Bicgstab(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$.
Available linear solvers can be queried with
ExaPF.LinearSolvers.list_solvers — Functionlist_solvers(::KernelAbstractions.Device)List linear solvers available on current device.
A default solver is provided for each vendor backend.
ExaPF.LinearSolvers.default_linear_solver — Functiondefault_linear_solver(A, ::KA.CPU)Default linear solver on the CPU.
ExaPF.jl provides an implementation of block-GMRES to solve linear systems with multiple righ-hand sides.
ExaPF.LinearSolvers.BlockKrylovSolver — TypeAbstract type for using block Krylov solvers in-place
ExaPF.LinearSolvers.BlockGmresSolver — TypeType for storing the vectors required by the in-place version of BLOCK-GMRES.
The outer constructors
solver = BlockGmresSolver(m, n, p, memory, SV, SM)
+solver = BlockGmresSolver(A, B; memory=5)may be used in order to create these vectors. memory is set to div(n,p) if the value given is larger than div(n,p).
ExaPF.LinearSolvers.block_gmres — Function(X, stats) = block_gmres(A, B; X0::AbstractMatrix{FC}; memory::Int=20, M=I, N=I,
ldiv::Bool=false, restart::Bool=false, reorthogonalization::Bool=false,
atol::T = √eps(T), rtol::T=√eps(T), itmax::Int=0,
- timemax::Float64=Inf, verbose::Int=0, history::Bool=false)T is an AbstractFloat such as Float32, Float64 or BigFloat. FC is T or Complex{T}.
(X, stats) = block_gmres(A, B, X0::AbstractVector; kwargs...)GMRES can be warm-started from an initial guess X0 where kwargs are the same keyword arguments as above.
Solve the linear system AX = B of size n with p right-hand sides using block-GMRES.
Input arguments
A: a linear operator that models a matrix of dimension n;B: a matrix of size n × p.Optional argument
X0: a matrix of size n × p that represents an initial guess of the solution X.Keyword arguments
memory: if restart = true, the restarted version block-GMRES(k) is used with k = memory. If restart = false, the parameter memory should be used as a hint of the number of iterations to limit dynamic memory allocations. Additional storage will be allocated if the number of iterations exceeds memory;M: linear operator that models a nonsingular matrix of size n used for left preconditioning;N: linear operator that models a nonsingular matrix of size n used for right preconditioning;ldiv: define whether the preconditioners use ldiv! or mul!;restart: restart the method after memory iterations;reorthogonalization: reorthogonalize the new matrices of the block-Krylov basis against all previous matrix;atol: absolute stopping tolerance based on the residual norm;rtol: relative stopping tolerance based on the residual norm;itmax: the maximum number of iterations. If itmax=0, the default number of iterations is set to 2 * div(n,p);timemax: the time limit in seconds;verbose: additional details can be displayed if verbose mode is enabled (verbose > 0). Information will be displayed every verbose iterations;history: collect additional statistics on the run such as residual norms.Output arguments
x: a dense matrix of size n × p;stats: statistics collected on the run in a BlockGmresStats.ExaPF.LinearSolvers.block_gmres! — Functionsolver = block_gmres!(solver::BlockGmresSolver, B; kwargs...)
-solver = block_gmres!(solver::BlockGmresSolver, B, X0; kwargs...)where kwargs are keyword arguments of block_gmres.
See BlockGmresSolver for more details about the solver.
Settings
This document was generated with Documenter.jl version 1.2.1 on Tuesday 5 December 2023. Using Julia version 1.9.4.
T is an AbstractFloat such as Float32, Float64 or BigFloat. FC is T or Complex{T}.
(X, stats) = block_gmres(A, B, X0::AbstractVector; kwargs...)GMRES can be warm-started from an initial guess X0 where kwargs are the same keyword arguments as above.
Solve the linear system AX = B of size n with p right-hand sides using block-GMRES.
Input arguments
A: a linear operator that models a matrix of dimension n;B: a matrix of size n × p.Optional argument
X0: a matrix of size n × p that represents an initial guess of the solution X.Keyword arguments
memory: if restart = true, the restarted version block-GMRES(k) is used with k = memory. If restart = false, the parameter memory should be used as a hint of the number of iterations to limit dynamic memory allocations. Additional storage will be allocated if the number of iterations exceeds memory;M: linear operator that models a nonsingular matrix of size n used for left preconditioning;N: linear operator that models a nonsingular matrix of size n used for right preconditioning;ldiv: define whether the preconditioners use ldiv! or mul!;restart: restart the method after memory iterations;reorthogonalization: reorthogonalize the new matrices of the block-Krylov basis against all previous matrix;atol: absolute stopping tolerance based on the residual norm;rtol: relative stopping tolerance based on the residual norm;itmax: the maximum number of iterations. If itmax=0, the default number of iterations is set to 2 * div(n,p);timemax: the time limit in seconds;verbose: additional details can be displayed if verbose mode is enabled (verbose > 0). Information will be displayed every verbose iterations;history: collect additional statistics on the run such as residual norms.Output arguments
x: a dense matrix of size n × p;stats: statistics collected on the run in a BlockGmresStats.ExaPF.LinearSolvers.block_gmres! — Functionsolver = block_gmres!(solver::BlockGmresSolver, B; kwargs...)
+solver = block_gmres!(solver::BlockGmresSolver, B, X0; kwargs...)where kwargs are keyword arguments of block_gmres.
See BlockGmresSolver for more details about the solver.
Settings
This document was generated with Documenter.jl version 1.2.1 on Thursday 7 December 2023. Using Julia version 1.9.4.