Linear Solve Operator Assumptions

LinearSolve.OperatorAssumptionsType
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): assume A may 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.

source
LinearSolve.OperatorConditionModule

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.

source
LinearSolve.NonstructuralZerosModule
EnumX.@enumx NonstructuralZeros

How 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.

source

Condition Number Specifications

Nonstructural Zero Specifications

LinearSolve.NonstructuralZeros.AutoConstant

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).

source
LinearSolve.NonstructuralZeros.NoneConstant

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.

source
LinearSolve.NonstructuralZeros.PersistentConstant

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.

source
LinearSolve.NonstructuralZeros.PresentConstant

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).

source