Linear Solve Operator Assumptions
LinearSolve.OperatorAssumptions — Type
OperatorAssumptions(issquare = nothing;
condition::OperatorCondition.T = IllConditioned,
nonstructural_zeros::NonstructuralZeros.T = Auto)Sets the operator A assumptions used as part of the default algorithm.
issquare asserts whether A is square (and thus whether a direct factorization vs. a least-squares solver is appropriate). nothing (default) defers the decision, letting init/defaultalg infer it from A.
condition describes the conditioning of A and selects how aggressively the default algorithm trades speed for stability (see OperatorCondition):
OperatorCondition.IllConditioned(default): assumeAmay be ill conditioned; pick a stability-preserving algorithm (e.g. pivoted factorizations).OperatorCondition.WellConditioned: assume contained conditioning and pick the fastest algorithm, skipping safety work.OperatorCondition.VeryIllConditioned/OperatorCondition.SuperIllConditioned: progressively more conservative, favoring the most numerically robust paths.
nonstructural_zeros declares how A's nonstructural zeros (stored entries that are numerically zero) behave across a sequence of solves, and hence whether and how a sparse factorization should drop them (see NonstructuralZeros):
NonstructuralZeros.Auto(default): detect from the starting matrix and adapt (cached union, falling back to per-solve dropzeros if non-persistent).NonstructuralZeros.None: none worth dropping; never reduce (bit-identical).NonstructuralZeros.Persistent: present at stable positions; cached-union reduction.NonstructuralZeros.Present: present but positions may vary; per-solve dropzeros.
Has no effect on dense A.
LinearSolve.OperatorCondition — Module
OperatorCondition
Specifies the assumption of matrix conditioning for the default linear solver choices. Condition number is defined as the ratio of eigenvalues. The numerical stability of many linear solver algorithms can be dependent on the condition number of the matrix. The condition number can be computed as:
using LinearAlgebra
cond(rand(100, 100))However, in practice this computation is very expensive and thus not possible for most practical cases. Therefore, OperatorCondition lets one share to LinearSolve the expected conditioning. The higher the expected condition number, the safer the algorithm needs to be and thus there is a trade-off between numerical performance and stability. By default the method assumes the operator may be ill-conditioned for the standard linear solvers to converge (such as LU-factorization), though more extreme ill-conditioning or well-conditioning could be the case and specified through this assumption.
LinearSolve.NonstructuralZeros — Module
EnumX.@enumx NonstructuralZerosHow a sparse operator's nonstructural zeros — stored entries that are numerically zero — are expected to behave across a sequence of solves. Such stored zeros (common in ODE/DAE Jacobians and W = I - γJ built from a conservative symbolic sparsity pattern) join the fill-reducing ordering and symbolic factorization as if real, inflating the factor, so dropping them speeds up every refactor and solve. Passed via OperatorAssumptions; has no effect on dense operators.
Condition Number Specifications
LinearSolve.OperatorCondition.IllConditioned — Constant
OperatorCondition.IllConditioned
The default assumption of LinearSolve. Assumes that the operator can have minor ill-conditioning and thus needs to use safe algorithms.
LinearSolve.OperatorCondition.VeryIllConditioned — Constant
OperatorCondition.VeryIllConditioned
Assumes that the operator can have fairly major ill-conditioning and thus the standard linear algebra algorithms cannot be used.
LinearSolve.OperatorCondition.SuperIllConditioned — Constant
OperatorCondition.SuperIllConditioned
Assumes that the operator can have fairly extreme ill-conditioning and thus the most stable algorithm is used.
LinearSolve.OperatorCondition.WellConditioned — Constant
OperatorCondition.WellConditioned
Assumes that the operator can have fairly contained conditioning and thus the fastest algorithm is used.
Nonstructural Zero Specifications
LinearSolve.NonstructuralZeros.Auto — Constant
NonstructuralZeros.Auto
Default. Detect from the starting matrix: enable the reduction when a sufficient fraction of the stored entries are numerically zero (see LinearSolve.PERSISTENT_ZERO_FRACTION_THRESHOLD), starting in cached-union mode and switching to per-solve dropzeros if the zeros prove non-persistent (more than LinearSolve.NONPERSISTENT_ZERO_FRACTION of the starting zeros activate).
LinearSolve.NonstructuralZeros.None — Constant
NonstructuralZeros.None
Assume the operator has no nonstructural zeros worth dropping. Never reduce — bit-for-bit identical to the plain factorization, with no detection overhead.
LinearSolve.NonstructuralZeros.Persistent — Constant
NonstructuralZeros.Persistent
Assume nonstructural zeros are present at persistent positions (the same entries stay zero across solves). Drop them via the cached union of ever-nonzero positions, reusing the symbolic factorization across solves.
LinearSolve.NonstructuralZeros.Present — Constant
NonstructuralZeros.Present
Assume nonstructural zeros are present but at positions that may vary between solves. Drop each matrix's own zeros per solve (no cross-solve symbolic caching; the inner solver re-analyzes when the pattern changes).