Revisit the post-processing by amontoison · Pull Request #267 · JuliaDiff/SparseMatrixColorings.jl · GitHub

close #264

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (a314d12) to head (262a09a).

Additional details and impacted files

@@            Coverage Diff             @@
##              main      #267    +/-   ##
==========================================
  Coverage   100.00%   100.00%            
==========================================
  Files           20        20            
  Lines         2027      2128   +101     
==========================================
+ Hits          2027      2128   +101

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Also, how does this all generalize to the acyclic bicoloring?

Also, how does this all generalize to the acyclic bicoloring?

It is exactly the same in terms of handling trivial edges.
The only difference is that we need to check the non-leaf nodes in non-trivial trees and mark them as needed for decompression, but this process is fully deterministic, just like checking hubs in non-trivial stars.

It was just late yesterday, and I didn’t find the energy to finalize the PR.
I will continue it tonight.

@gdalle I have an issue in my new function postprocess_star_bicoloring, I need to check if the hub h is in the column partition (1 <= h <= n) or the row partition (n+1 <= h <= n+m) but I didn't find a way to obtain n or m from the arguments.
Because we pass the AdjacencyGraph of the augmented matrix, we can only recover n+m.

We could store this information in the adjacency graph, to know whether it comes from a symmetric matrix or not, and in the latter case have access to the row/column split

Or we pass an additional argument to the coloring

We could store this information in the adjacency graph, to know whether it comes from a symmetric matrix or not, and in the latter case have access to the row/column split

I prefer this approach because we can know that we have "augmented adjacency matrix" this way, and thus know that we are in bicoloring context for the function postprocess!.

I will not need to pass the boolean parameter bicoloring everywhere.

I suggest replacing AdjacencyGraph with:

struct AdjacencyGraph{T<:Integer,bicoloring}
    S::SparsityPatternCSC{T}
    edge_to_index::Vector{T}
    original_size::Tuple{Int,Int}
end

We no longer need has_diagonal because we have bicoloring => !has_diagonal

I suggest replacing AdjacencyGraph with:

struct AdjacencyGraph{T<:Integer,bicoloring}
    S::SparsityPatternCSC{T}
    edge_to_index::Vector{T}
    original_size::Tuple{Int,Int}
end

Ok for me 👍

We no longer need has_diagonal because we have bicoloring => !has_diagonal

Yes but we don't have !has_diagonal => bicoloring. Is it fine for you that the user can't specify anymore has_diagonal = false in a non-bicoloring case?

I think adding a field bicoloring::Bool in AdjacencyGraph can handle more corner cases.

Yes but we don't have !has_diagonal => bicoloring. Is it fine for you that the user can't specify anymore has_diagonal = false in a non-bicoloring case?

has_diagonal was never part of our public API to begin with, so the user never gets to specify it. I think the cases where someone wants to color a Hessian whose entire diagonal is zero are sufficiently rare for us to ignore them.
In addition, they would lead to type instabilities because they require a check on the values of the matrix before creating the AdjacencyGraph object.

has_diagonal was never part of our public API to begin with, so the user never gets to specify it. I think the cases where someone wants to color a Hessian whose entire diagonal is zero are sufficiently rare for us to ignore them.

Fair point 👍
I updated the PR.

Aside from my remarks above, do you have any ideas for test cases where our heuristics actually produce the result we want?

Aside from my remarks above, do you have any ideas for test cases where our heuristics actually produce the result we want?

@gdalle I added the heuristic that I quickly described on Messenger in the following commit: 5fa3f7a
I only need to fuse the post-processing functions together and it should be good.

@gdalle It is finally ready for a review!!

@gdalle I don't know what to do for the code coverage of the last two missing lines.
One solution is to run many tests with the acyclic coloring + random order and find one case for the arrowhead matrix that works.

Isn't it a bit worrying that across all of our randomized tests we don't hit this case even once? I think that should tell us to pause and think about why

I did some tests and it is because he always got a par for the number columns / rows to neutralize per color.
Using more rectangular random problems could help.

It is harder to get trivial edges in acyclic coloring than star coloring.

@gdalle I was able to run the code in the two lines not covered by the unit tests with a random order and the following matrices:

6×12 SparseMatrixCSC{Float64, Int64} with 11 stored entries:
  ⋅   1.0   ⋅    ⋅    ⋅   1.0   ⋅    ⋅   1.0   ⋅    ⋅    ⋅ 
  ⋅    ⋅    ⋅    ⋅    ⋅    ⋅    ⋅   1.0   ⋅    ⋅    ⋅    ⋅ 
  ⋅   1.0  1.0   ⋅    ⋅    ⋅    ⋅    ⋅    ⋅    ⋅    ⋅    ⋅ 
  ⋅    ⋅   1.0   ⋅    ⋅    ⋅    ⋅    ⋅    ⋅    ⋅    ⋅    ⋅ 
  ⋅    ⋅    ⋅    ⋅    ⋅    ⋅    ⋅    ⋅   1.0   ⋅    ⋅   1.0
  ⋅    ⋅    ⋅   1.0   ⋅    ⋅   1.0   ⋅    ⋅    ⋅    ⋅    ⋅ 

6×12 SparseMatrixCSC{Float64, Int64} with 11 stored entries:
  ⋅    ⋅    ⋅    ⋅    ⋅    ⋅    ⋅    ⋅    ⋅    ⋅    ⋅    ⋅ 
  ⋅    ⋅    ⋅    ⋅    ⋅    ⋅   1.0   ⋅    ⋅   1.0  1.0   ⋅ 
  ⋅    ⋅    ⋅    ⋅   1.0   ⋅    ⋅    ⋅   1.0   ⋅    ⋅    ⋅ 
  ⋅    ⋅   1.0   ⋅    ⋅    ⋅    ⋅    ⋅   1.0   ⋅    ⋅    ⋅ 
  ⋅    ⋅    ⋅   1.0   ⋅   1.0   ⋅   1.0   ⋅    ⋅    ⋅    ⋅ 
  ⋅    ⋅    ⋅    ⋅    ⋅    ⋅    ⋅   1.0   ⋅    ⋅    ⋅    ⋅

3×6 SparseMatrixCSC{Float64, Int64} with 6 stored entries:
 1.0   ⋅   1.0  1.0   ⋅    ⋅ 
  ⋅    ⋅    ⋅    ⋅   1.0   ⋅ 
  ⋅    ⋅    ⋅   1.0   ⋅   1.0

3×6 SparseMatrixCSC{Float64, Int64} with 5 stored entries:
 1.0   ⋅    ⋅    ⋅    ⋅    ⋅ 
  ⋅   1.0  1.0   ⋅    ⋅   1.0
  ⋅   1.0   ⋅    ⋅    ⋅    ⋅ 

3×6 SparseMatrixCSC{Float64, Int64} with 7 stored entries:
  ⋅    ⋅    ⋅    ⋅   1.0   ⋅ 
  ⋅    ⋅   1.0   ⋅    ⋅   1.0
 1.0  1.0  1.0   ⋅   1.0   ⋅ 

3×5 SparseMatrixCSC{Float64, Int64} with 5 stored entries:
  ⋅   1.0  1.0  1.0   ⋅ 
 1.0   ⋅    ⋅    ⋅    ⋅ 
  ⋅    ⋅   1.0   ⋅    ⋅ 

3×4 SparseMatrixCSC{Float64, Int64} with 5 stored entries:
  ⋅   1.0  1.0   ⋅ 
  ⋅    ⋅    ⋅   1.0
 1.0   ⋅   1.0   ⋅

3×4 SparseMatrixCSC{Float64, Int64} with 6 stored entries:
  ⋅    ⋅    ⋅   1.0
 1.0  1.0   ⋅    ⋅ 
 1.0   ⋅   1.0  1.0

3×4 SparseMatrixCSC{Float64, Int64} with 4 stored entries:
  ⋅    ⋅   1.0  1.0
  ⋅    ⋅   1.0   ⋅ 
 1.0   ⋅    ⋅    ⋅ 

3×4 SparseMatrixCSC{Float64, Int64} with 6 stored entries:
 1.0  1.0   ⋅   1.0
 1.0   ⋅    ⋅    ⋅ 
  ⋅   1.0  1.0   ⋅ 

3×3 SparseMatrixCSC{Float64, Int64} with 4 stored entries:
  ⋅   1.0   ⋅ 
 1.0   ⋅   1.0
  ⋅    ⋅   1.0

3×3 SparseMatrixCSC{Float64, Int64} with 4 stored entries:
 1.0   ⋅   1.0
 1.0   ⋅    ⋅ 
  ⋅   1.0   ⋅ 

3×3 SparseMatrixCSC{Float64, Int64} with 4 stored entries:
 1.0  1.0   ⋅ 
  ⋅    ⋅   1.0
  ⋅   1.0   ⋅

I will add the 3x3 matrix in the tests and we should be good.

Thanks!
I'm still on vacation but I'll review when I get back to work

For after the holidays 🏖️ 🎅

I followed your suggestion Guillaume, and tried to check the impact of postprocessing on a collection of “real” problems.
I downloaded all 846 matrices from the SuiteSparse Matrix Collection where the number of rows and columns is between 1000 and 10000, and I checked the number of problems on which postprocessing results in a gain in total colors.

It also helped me detect that I had forgotten to split unused row and column colors at the end of postprocessing (for the bicoloring), which drastically changed the results. See this commit: e999c65.
Initially, I got worse results than the dummy heuristic we currently have on main!

Before the PR (on the branch main), the results are:

star_bicoloring | random | 18 / 846
star_bicoloring | natural | 794 / 846
star_bicoloring | largest_first | 532 / 846
star_bicoloring | smallest_last | 508 / 846
star_bicoloring | indidence_degree | 214 / 846
star_bicoloring | dynnamic_largest_first | 305 / 846

acyclic_bicoloring | random | 14 / 846
acyclic_bicoloring | natural | 76 / 846
acyclic_bicoloring | largest_first | 52 / 846
acyclic_bicoloring | smallest_last | 41 / 846
acyclic_bicoloring | indidence_degree | 9 / 846
acyclic_bicoloring | dynnamic_largest_first | 65 / 846

and with this PR:

star_bicoloring | random | :all_colors | 29 / 846
star_bicoloring | random | :row_colors | 29 / 846
star_bicoloring | random | :column_colors | 29 / 846

star_bicoloring | natural | :all_colors | 837 / 846
star_bicoloring | natural | :row_colors | 837 / 846
star_bicoloring | natural | :column_colors | 837 / 846

star_bicoloring | largest_first | :all_colors | 605 / 846
star_bicoloring | largest_first | :row_colors | 605 / 846
star_bicoloring | largest_first | :column_colors | 605 / 846

star_bicoloring | smallest_last | :all_colors | 594 / 846
star_bicoloring | smallest_last | :row_colors | 594 / 846
star_bicoloring | smallest_last | :column_colors | 594 / 846

star_bicoloring | indidence_degree | :all_colors | 523 / 846
star_bicoloring | indidence_degree | :row_colors | 523 / 846
star_bicoloring | indidence_degree | :column_colors | 523 / 846

star_bicoloring | dynamic_largest_first | :all_colors | 415 / 846
star_bicoloring | dynamic_largest_first | :row_colors | 415 / 846
star_bicoloring | dynamic_largest_first | :column_colors | 415 / 846

acyclic_bicoloring | random | :all_colors | 28 / 846
acyclic_bicoloring | random | :row_colors | 28 / 846
acyclic_bicoloring | random | :column_colors | 28 / 846

acyclic_bicoloring | natural | :all_colors | 141 / 846
acyclic_bicoloring | natural | :row_colors | 141 / 846
acyclic_bicoloring | natural | :column_colors | 141 / 846

acyclic_bicoloring | largest_first | :all_colors | 99 / 846
acyclic_bicoloring | largest_first | :row_colors | 99 / 846
acyclic_bicoloring | largest_first | :column_colors | 99 / 846

acyclic_bicoloring | smallest_last | :all_colors | 84 / 846
acyclic_bicoloring | smallest_last | :row_colors | 84 / 846
acyclic_bicoloring | smallest_last | :column_colors | 84 / 846

acyclic_bicoloring | indidence_degree | :all_colors | 68 / 846
acyclic_bicoloring | indidence_degree | :row_colors | 68 / 846
acyclic_bicoloring | indidence_degree | :column_colors | 68 / 846

acyclic_bicoloring | dynamic_largest_first | :all_colors | 197 / 846
acyclic_bicoloring | dynamic_largest_first | :row_colors | 197 / 846
acyclic_bicoloring | dynamic_largest_first | :column_colors | 197 / 846

The number of problems showing an improvement is independent of postprocessing_minimizes (on the subset of 846 matrices).
We can observe that, depending on the ordering, the number of problems showing an improvement after postprocessing varies greatly.
Postprocessing has more impact on star bicoloring than on acyclic bicoloring.
I explain this by the fact that acyclic bicoloring allows more complex graph structures (trees) than star bicoloring (stars), which probably limits the number of trivial edges.
I will perform a similar run for symmetric matrices to compare star coloring and acyclic coloring.

The code that I used is:

using SparseMatrixColorings
using SuiteSparseMatrixCollection
using MatrixMarket
using StableRNGs

ssmc = ssmc_db()
matrices = ssmc[(1000 .≤ ssmc.nrows) .& (ssmc.nrows .≤ 10000) .& (1000 .≤ ssmc.ncols) .& (ssmc.ncols .≤ 10000), :]
paths = fetch_ssmc(matrices, format="MM")
nmatrices = length(paths)

stats = Dict{String, Dict{Symbol, Dict{String, Dict{Symbol, Tuple{Int,Int,Int}}}}}()
verbose = false
legacy = false

decompressions = [("star_bicoloring", :direct),
                  ("acyclic_bicoloring", :substitution)]

orders = [("random", RandomOrder(StableRNG(0), 0)),
          ("natural", NaturalOrder()),
          ("largest_first", LargestFirst()),
          ("smallest_last", SmallestLast()),
          ("indidence_degree", IncidenceDegree()),
          ("dynamic_largest_first" , DynamicLargestFirst())]

variants_pp = legacy ? (:none, :default) : (:none, :all_colors, :row_colors, :column_colors)

for i = 1:nmatrices
  name = matrices.name[i]
  stats[name] = Dict{Symbol, Dict{String, Dict{Symbol, Tuple{Int,Int,Int}}}}()
  path = joinpath(paths[i], "$(name).mtx")
  A = MatrixMarket.mmread(path) 
  for decompression in (:direct, :substitution)
    stats[name][decompression] = Dict{String, Dict{Symbol, Tuple{Int,Int,Int}}}()
    for (ordering, order) in orders
      stats[name][decompression][ordering] = Dict{Symbol, Tuple{Int,Int,Int}}()
      for postprocessing_minimizes in variants_pp
        postprocessing = (postprocessing_minimizes == :none) ? false : true
        verbose && println("matrix = $name | decompression = $decompression | order = $ordering | postprocessing = $postprocessing")
        problem = ColoringProblem(; structure=:nonsymmetric, partition=:bidirectional)
        if legacy
          algo = GreedyColoringAlgorithm(order; decompression, postprocessing)
        else
          algo = GreedyColoringAlgorithm(order; decompression, postprocessing, postprocessing_minimizes)
        end
        result = coloring(A, problem, algo)
        ncolors_row = row_groups(result) |> length
        ncolors_col = column_groups(result) |> length
        verbose && println("rcolors: $ncolors_row | ccolors: $ncolors_col")
        stats[name][decompression][ordering][postprocessing_minimizes] = (ncolors_row, ncolors_col, ncolors_row + ncolors_col)
      end
      verbose && println()
    end
    verbose && println("-----------------------------------------------")
  end
end

if legacy
  for (bicoloring, decompression) in decompressions
    for (ordering, order) in orders
      gain = 0
      for i = 1:nmatrices
        name = matrices.name[i]
        (r0,c0,s0) = stats[name][decompression][ordering][:none]
        (r1,c1,s1) = stats[name][decompression][ordering][:default]
        (s1 < s0) && (gain += 1)
      end
      println("$bicoloring | $ordering | $gain / $nmatrices")
    end
  end
else
  for (bicoloring, decompression) in decompressions
    for (ordering, order) in orders
      gain1 = 0  # all_colors
      gain2 = 0  # row_colors
      gain3 = 0  # column_colors
      for i = 1:nmatrices
        name = matrices.name[i]
        (r0,c0,s0) = stats[name][decompression][ordering][:none]
        (r1,c1,s1) = stats[name][decompression][ordering][:all_colors]
        (r2,c2,s2) = stats[name][decompression][ordering][:row_colors]
        (r3,c3,s3) = stats[name][decompression][ordering][:column_colors]
        (s1 < s0) && (gain1 += 1)
        (s2 < s0) && (gain2 += 1)
        (s3 < s0) && (gain3 += 1) 
      end
      println("$bicoloring | $ordering | :all_colors | $gain1 / $nmatrices")
      println("$bicoloring | $ordering | :row_colors | $gain2 / $nmatrices")
      println("$bicoloring | $ordering | :column_colors | $gain3 / $nmatrices")
    end
  end
end

The variable legacy is used to specify if we run the code on the branch main or not.

Thanks for running the tests! If I understand correctly, the takeaways are:

The new postprocessing reduces the number of colors for a larger set of instances
It is unclear whether the postprocessing_minimizes argument actually changes anything
The order has a big impact, which to me suggests that we should try using it not just when we initially assign colors, but also when we go back through the list of vertices to mark them as essential or not (e.g. here)

The new postprocessing reduces the number of colors for a larger set of instances

Yes, but only for bicoloring, I didn't see any difference with the new post-processing for star and acyclic colorings.

It is unclear whether the postprocessing_minimizes argument actually changes anything

The total number of colors doesn't change with postprocessing_minimizes but we remove more row or column colors depending on it.

The order has a big impact, which to me suggests that we should try using it not just when we initially assign colors, but also when we go back through the list of vertices to mark them as essential or not (e.g. here)

It doesn't change anything at the line that you specified.
Whatever is the order of the vertices, we just mark necessary or not (independent or the ordering).

What is important is the order of treatment of the trivial trees or stars (last step of post-processing).

What is important is the order of treatment of the trivial trees or stars (last step of post-processing).

Sorry, yes, replace the line I pointed to with e.g. these ones. Perhaps there we could permute stars or trees according to the same order used for coloring, or its reverse order?

What is important is the order of treatment of the trivial trees or stars (last step of post-processing).

Sorry, yes, replace the line I pointed to with e.g. these ones. Perhaps there we could permute stars or trees according to the same order used for coloring, or its reverse order?

For the acyclic coloring, we store ane iterate over the list of trees, so I don't have any idea about how we could use the ordering of the vertices for that.

For the star coloring, we iterate over the stars multiple times. We iterate over the star of each vertex and not the stars directly (we can't because we only encode the hub and not the spokes in our implementation of the stars).
But what we want in pratice is to iterate over the stars and I don't know how we can permute them based on the ordering of the vertices.

It is an opened question and the treatment of the trivial stars / trees is a standalone new graph problem from what I understand. We have something to dig here if we want.

We should not forget to explain it in our paper when we will get the review.

@gdalle Can we merge this PR?

I'll take a cursory look today or tomorrow

(Check your DMs)

amontoison requested a review from gdalle October 14, 2025 04:48

amontoison commented Oct 14, 2025

View reviewed changes

Comment thread src/coloring.jl Outdated

amontoison commented Oct 14, 2025

View reviewed changes

Comment thread src/coloring.jl Outdated

amontoison marked this pull request as draft October 14, 2025 04:54

amontoison commented Oct 14, 2025

View reviewed changes

Comment thread src/coloring.jl Outdated

amontoison commented Oct 14, 2025

View reviewed changes

Comment thread src/coloring.jl Outdated

gdalle reviewed Oct 14, 2025

View reviewed changes

Comment thread src/coloring.jl Outdated

Comment thread src/coloring.jl Outdated

gdalle mentioned this pull request Oct 20, 2025

Make any coloring algorithm compatible with SMC #263

Merged

3 tasks

amontoison force-pushed the am/postprocessing_v2 branch 2 times, most recently from 6134b6b to 126f4bb Compare October 23, 2025 08:21

amontoison marked this pull request as ready for review October 24, 2025 17:12

amontoison requested a review from gdalle October 24, 2025 17:12

amontoison commented Oct 24, 2025

View reviewed changes

Comment thread test/suitesparse.jl Outdated

amontoison changed the title Add an option neutralized_first in the post-processing Revisit the post-processing Oct 24, 2025

gdalle requested changes Oct 29, 2025

View reviewed changes

Comment thread src/postprocessing.jl Outdated

Comment thread src/interface.jl Outdated

Comment thread test/small.jl Outdated

Comment thread src/graph.jl Outdated

Comment thread src/postprocessing.jl Outdated

Comment thread src/postprocessing.jl

Comment thread src/postprocessing.jl Outdated

amontoison force-pushed the am/postprocessing_v2 branch from ec642b2 to 84004ad Compare November 1, 2025 06:19

gdalle mentioned this pull request Nov 1, 2025

Rename has_diagonal into augmented_graph #273

Merged

amontoison force-pushed the am/postprocessing_v2 branch from 6a96b9d to 933308a Compare November 1, 2025 15:21

amontoison mentioned this pull request Nov 3, 2025

Add postprocess_with_star_set! and postprocess_with_tree_set! #279

Merged

amontoison force-pushed the am/postprocessing_v2 branch from 5fa3f7a to a37c7b7 Compare November 3, 2025 07:53

gdalle mentioned this pull request Nov 4, 2025

Use mixed mode AD for Jac evaluation Deltares/Ribasim#2605

Closed

amontoison force-pushed the am/postprocessing_v2 branch from a132593 to 6b0fbb1 Compare November 5, 2025 04:30

amontoison requested a review from gdalle November 5, 2025 04:30

amontoison force-pushed the am/postprocessing_v2 branch from 3ed7996 to 1667b52 Compare December 15, 2025 07:55

amontoison force-pushed the am/postprocessing_v2 branch 2 times, most recently from 60a05be to b993df6 Compare December 29, 2025 06:00

amontoison force-pushed the am/postprocessing_v2 branch from 904eb07 to 87c8016 Compare December 31, 2025 10:20

amontoison force-pushed the am/postprocessing_v2 branch 2 times, most recently from b7bd4a8 to be8da65 Compare January 6, 2026 15:52

Revisit the post-processing

262a09a

amontoison force-pushed the am/postprocessing_v2 branch from be8da65 to 262a09a Compare January 9, 2026 19:51

Revisit the post-processing by amontoison · Pull Request #267 · JuliaDiff/SparseMatrixColorings.jl · GitHub

Uh oh!

Revisit the post-processing - #267

Revisit the post-processing #267amontoison wants to merge 1 commit intomainJuliaDiff/SparseMatrixColorings.jl:mainfrom am/postprocessing_v2JuliaDiff/SparseMatrixColorings.jl:am/postprocessing_v2Copy head branch name to clipboard

Conversation

amontoison commented Oct 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

codecov Bot commented Oct 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

gdalle commented Oct 14, 2025

Uh oh!

amontoison commented Oct 14, 2025

Uh oh!

amontoison commented Oct 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gdalle commented Oct 24, 2025

Uh oh!

gdalle commented Oct 24, 2025

Uh oh!

amontoison commented Oct 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gdalle commented Oct 24, 2025

Uh oh!

amontoison commented Oct 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gdalle commented Oct 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

amontoison commented Oct 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

gdalle left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

amontoison commented Nov 3, 2025

Uh oh!

amontoison commented Nov 5, 2025

Uh oh!

amontoison commented Dec 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gdalle commented Dec 18, 2025

Uh oh!

amontoison commented Dec 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

amontoison commented Dec 29, 2025

Uh oh!

gdalle commented Dec 29, 2025

Uh oh!

amontoison commented Dec 30, 2025

Uh oh!

amontoison commented Dec 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gdalle commented Jan 6, 2026

Uh oh!

amontoison commented Jan 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Revisit the post-processing #267
amontoison wants to merge 1 commit into
mainfrom
am/postprocessing_v2

amontoison commented Oct 14, 2025 •
edited
Loading

codecov Bot commented Oct 14, 2025 •
edited
Loading

amontoison commented Oct 24, 2025 •
edited
Loading

amontoison commented Oct 24, 2025 •
edited
Loading

amontoison commented Oct 24, 2025 •
edited
Loading

gdalle commented Oct 24, 2025 •
edited
Loading

amontoison commented Oct 24, 2025 •
edited
Loading

amontoison commented Dec 15, 2025 •
edited
Loading

amontoison commented Dec 18, 2025 •
edited
Loading

amontoison commented Dec 30, 2025 •
edited
Loading

amontoison commented Jan 6, 2026 •
edited
Loading

amontoison commented Jan 6, 2026 •
edited
Loading