Struct BlockMatrix 

pub struct BlockMatrix { /* private fields */ }

A mutable block-COO Y-bus/Jacobian accumulator: one 2×2 block per (bus, bus) slot instead of network::YBus’s one Complex<f64> per (unknown, unknown) slot. Duplicate (i, j) entries are summed once finalized, matching YBus’s accumulation semantics.

Implementations

impl BlockMatrix

pub fn new(n: usize) -> Self

pub fn add(&mut self, i: usize, j: usize, block: Block2)

pub fn n(&self) -> usize

pub fn finish(self) -> BlockAdjacency

Consolidates duplicate (i, j) entries (summing them) and returns a row-major and column-major adjacency list: row(i) gives all (j, block) pairs with a nonzero block in row i (including the diagonal), col(j) gives all (i, block) pairs with a nonzero block in column j — both sorted by the other index. Kept as two separate views (not just one, transposed on demand) because the real power-flow Jacobian is not value-symmetric (block(i, j) != block(j, i) in general, even though the sparsity pattern is structurally symmetric) — BlockLu::refactor genuinely needs column j’s own values, not row j’s reused under a symmetry assumption that doesn’t hold for this matrix.

Sort-based, not hash-based: newton_raphson_block calls this once per iteration (the Jacobian’s numeric values change every iteration even though its sparsity pattern doesn’t), so this runs thousands of times per solve on realistic networks — profiling with perf showed a HashMap-based merge costing ~25% of total block-backend runtime at 2,605 nodes. Sorting by (i, j) avoids hashing entirely and leaves each row already grouped in ascending-j order, so no separate per-row sort is needed afterwards either; iterating that same ascending-i order while building cols likewise leaves each column already grouped in ascending-i order for free.