Per-solver exclusions (which solver/experiment combinations don't work, and why) are currently scattered across mosaic/benchmarks/problems/*/exclusions.py files. This information is valuable for users choosing solvers but hard to discover.
Goal: Generate a human-readable capability matrix and include it in the docs. For each domain, show a table like:
| Solver |
forward |
gradient |
cost |
optimization |
Notes |
| FEniCS |
✓ |
✓ |
✓ |
✓ |
|
| deal.II |
✓ |
— |
fwd only |
— |
No AD path (C++) |
| ... |
|
|
|
|
|
This could be:
- A static table in
docs/solvers.qmd, or
- Auto-generated from the exclusion data (similar to how
docs/generate.py builds the solver reference)
The exclusion objects already carry structured category and reason fields, so the data is machine-readable.
Per-solver exclusions (which solver/experiment combinations don't work, and why) are currently scattered across
mosaic/benchmarks/problems/*/exclusions.pyfiles. This information is valuable for users choosing solvers but hard to discover.Goal: Generate a human-readable capability matrix and include it in the docs. For each domain, show a table like:
This could be:
docs/solvers.qmd, ordocs/generate.pybuilds the solver reference)The exclusion objects already carry structured
categoryandreasonfields, so the data is machine-readable.