Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
A small experiment to see how we could go about enabling indirect KKT solves. This PR so far does the following:
adds a registration mechanism for AbstractKKTSolver implementations. This uses a Dict object implemented similarly to the registration method for the direct LDL solvers. This requires a minor change to the Settings structure, which now defines a default
kkt_solver_method = :directldl
to get the standard solver behaviour.adds a new prototype implementation for a
IndirectKKTSolver
solver type, which can be selected via the optionkkt_solver_method = :indirect
. This is very basic and assumes internally that it will only be applied to a problem with a single NN cone constraint. It does not actually implement an indirect solve, but rather reduces the KKT system to a dense form to which an an actual indirect linear solver could be applied.makes some internal modifications to the rest of the code to support the indirect solve, mostly by passing
cones
around where they are required.Note that if an indirect method is used then there is no reason that
SparseMatrixCSC
format is required, since in that case the solver only needs to perform matrix multiplication. (Almost) everything is implemented internally in terms ofAbstractMatrix{T}
, so the solver should work on any input type that implements enough ofAbstractMatrix{T}
interface. See example below for further explanation.This is WIP and should not be used in anger. It is currently unclear to me how this could be applied to general cone problems since it requires the inverse of the scaling block Hs, or at least multiplication by the inverse of that block. See internal comments in the
kktsolver_indirect.jl
implementation for further explanation.Example code: