Skip to main content

Crate gridoxide

Crate gridoxide 

Source

Modules§

ac_sensitivity
AC sensitivity analysis: how a converged operating point responds to a small change.
batch
Batched power flow: one topology, many scenarios, solved across all cores.
bde
Block-diagonal embedding: solve B scenarios as one sparse system.
block_sparse
Experimental block-per-bus sparse LU backend for symmetric power flow, mirroring power-grid-model’s approach of grouping each bus’s own unknowns (angle, voltage magnitude) into one dense 2×2 block instead of two separate scalar unknowns scattered across the Jacobian.
branch_flow
Branch terminal power flows and their partial derivatives.
capi
A C ABI, so a C++ project can embed gridoxide.
cgmes
CGMES (Common Grid Model Exchange Standard) dataset loading and conversion, built on cimoxide’s cimoxide-model crate (cimmodel) — see docs/src/reference/provenance.md.
constrained
A switch as an exact equality constraint, rather than as a stiff branch.
continuation
Continuation power flow: how much further can this network be loaded?
dc
Real-valued DC network model and Newton-Raphson solver.
dispatch
Which machine produced what reactive power.
dynamics
RMS (phasor-domain) dynamic simulation: what the network does over time after a disturbance.
iidm
PowSyBl IIDM (.xiidm) network import.
injection_hessian
Second derivatives of the bus power injections.
jacobian
Topology-derived Jacobian assembly: analyze the sparsity pattern once, then refill values every iteration at fixed offsets.
json
klu_native
A from-scratch Rust port of the vendored SuiteSparse KLU solver (vendor/suitesparse/{BTF,AMD,KLU}/, v7.12.2 — see vendor/suitesparse/PROVENANCE.md for the upstream tag/commit this was ported from) — a fourth, always-built JacobianBackend alongside Scalar, Block, and the FFI-backed Klu (sparse_klu.rs).
linear
Linearized power-flow methods: the two different things the literature and the reference tools both call “linear power flow”.
load
A network read from any of the importers, and an AC power flow over it.
lu
The sparse LU backend, chosen at run time.
matpower
MATPOWER case import (.m).
measurement
The measurement model state estimation is fitted against: what was observed, where, and how much it is trusted.
network
opf
The optimization layer: a solver-independent problem statement, and whatever backend is available to answer it.
outerloop
Outer loops: the controls that sit around a Newton-Raphson solve.
pgm
qv
Q-V curves: how much reactive headroom does one bus have?
rao
Remedial action optimization.
ratings
Branch operating limits — the permanent rating and its temporary overload allowances.
roots
Bracketed root finding, shared by the event locators in continuation and gridoxide’s dynamics.
scenario
What a batch varies: per-bus overrides and branch outages against a shared template, and the errors a batch reports for them.
se
State estimation: recovering the most likely grid state from noisy, redundant, partial measurements.
shortcircuit
Short-circuit calculation, IEC 60909 style.
solver
sparse
Thin internal wrapper around faer’s sparse LU, isolating gridoxide’s power-flow math from the specific sparse-solver backend. Both a general (non-symmetric, since phase-shifting transformers make the admittance matrix non-Hermitian) complex solve and a real solve are provided, since Newton-Raphson needs the latter for its Jacobian and the linear initial-guess warm start needs the former for the Y-bus.
switches
Giving a retained switch a formulation.
topology
Network topology: the node/switch graph, and the reductions over it.
types
ucte
UCTE-DEF network import.

Structs§

OuterLoopOutcome
The outer loops’ side of a solve, gathered so a caller need not downcast outerloop::OuterLoop trait objects to read their reports.
PowerFlowOptions
Everything crate::run_power_flow needs to know.
PowerFlowReport
Result of a full power-flow analysis: the solved (or placeholder, for unreferenced islands) buses, plus a per-connected-component breakdown of how each one was resolved — see solver::IslandReport/ solver::IslandStatus.
RemoteControlData
The regulating machines a solve may act on.
TapData
The tap tables and regulating controls a solve may act on.

Enums§

PowerFlowInit
Where PowerFlowMethod::NewtonRaphson starts from. Ignored by the direct methods, which have no starting point.
PowerFlowMethod
Which method crate::run_power_flow uses.

Functions§

initialize_newton
Sets Newton’s starting point in buses, as run_power_flow does before its first iteration.
run_power_flow
Runs a power flow by the method named in opts.
run_power_flow_analysis
run_power_flow_analysis_from_ybus
Runs a power flow analysis given a pre-built Y-bus matrix. Intended for the 3-phase case too, where buses is a 3N-element vector and ybus is the 3N×3N phase-domain admittance matrix from build_ybus_3ph — a physical bus’s 3 phase-rows always share the same BusType, so the island partitioning PersistentSolver::solve does internally is safe for that case too (worst case, in a network with perfectly balanced zero/positive-sequence impedances, phases may partition into separate components rather than staying grouped by physical bus; each still carries its own valid reference, so this doesn’t change correctness, only granularity).
run_power_flow_with_remote
run_power_flow with the regulating machines a remote-voltage control needs. The two-argument form is the shorter path for every caller that has none, which is every importer but CGMES.