Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement coloring when the color vector is known #124

Closed
gdalle opened this issue Sep 27, 2024 · 4 comments · Fixed by #127
Closed

Implement coloring when the color vector is known #124

gdalle opened this issue Sep 27, 2024 · 4 comments · Fixed by #127
Labels
feature New feature or extension

Comments

@gdalle
Copy link
Owner

gdalle commented Sep 27, 2024

This is needed in SciML, see SciML/NonlinearSolve.jl#415

Related to #67

@gdalle gdalle added the feature New feature or extension label Sep 27, 2024
@gdalle gdalle mentioned this issue Sep 27, 2024
8 tasks
@amontoison
Copy link
Collaborator

amontoison commented Sep 27, 2024

I don't think that rebuilding a StarSet or TreeSet from scratch will be relevant for symmetric coloring.
We have a similar paradigm when we compute a fill-in permutation with METIS in linear algebra; we also obtain the sparsity pattern of the factors during the computation.
Just providing the permutation is slower because the sparse linear solver needs to recover the sparsity pattern of the factors from scratch.
It's not a good idea in practice.

@gdalle
Copy link
Owner Author

gdalle commented Sep 27, 2024

You're absolutely right, for Hessian coloring this is not a good idea, we cannot recover the stars or trees if all we have is the vector of colors.
However the SciML application (@avik-pal's LinearSolve.jl) is only for Jacobian colorings. In that case, we can easily reconstruct a result and use it for decompression.
The idea is that for some matrix structures, we can know the optimal coloring without even running an algorithm, and so they want to leverage that. But these optimal colorings are not defined for symmetric matrices anyway (no one cared about those before we came along) so we don't need to worry about it yet, or maybe ever.

@amontoison
Copy link
Collaborator

@gdalle
Copy link
Owner Author

gdalle commented Sep 27, 2024

You're right, the functionality we need is there, but the specific result types are not part of our public API, and I think it's a good idea to keep it that way because it allows some flexibility on our end.
The way SciML will interact with this code is through DI, namely through an AutoSparse object and its coloring_algorithm field. So what I need to do is implement some kind of trivial ColoringAlgorithmWithKnownColors that always returns the same ColumnColoringResult or RowColoringResult (and errors e.g. if the provided matrix doesn't have the right size, or if you ask it for a symmetric coloring).
This sounds silly but it is the same idea as KnownJacobianSparsityDetector from ADTypes. It allows separation of concerns without them having to dig into how results are stored.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature or extension
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants