perm_row of a uniform LU batch reports batch member 1 only
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 68/100
Research direction
Start in src/solver.jl at the "perm_row" branch of getparam (structure "G", stage at or beyond factorized) and compare it with the per-member branches for "info", "npivots", "inertia", "pivot_stats" and "diag". Read the docstring table that documents "batch member 1", and the getparam! entry points that would need to accept an n × nbatch result. Before changing anything, check what cuDSS returns for CUDSS_DATA_PERM_ROW on a uniform batch. Done means perm_row either returns one column per batch member consistently with "diag" (and getparam! handles it), or the docstring explicitly states member-1-only is by design.
Written by the indexing model from the issue text.
Description
Found while working on: T19 (PR #85), review nit.
What: getparam(solver, "perm_row") in src/solver.jl (the "perm_row" branch of getparam, structure "G", stage ≥ factorized) returns sp.perm[piv[1:n]], i.e. the reordering composed with the local row interchanges of batch member 1 only. In a uniform batch every member pivots independently and has its own row order, so members 2..nbatch get no perm_row. Every other per-member output ("info", "npivots", "inertia", "pivot_stats", "diag") is returned per member. The docstring table already says "batch member 1", so the behaviour is documented, but it differs from the other per-member outputs.
Why it is out of scope: T19 delivered LU with uniform batches; the per-member output shape is an API decision. It is not in TASKS.md and blocks no later task. Check what cuDSS returns for CUDSS_DATA_PERM_ROW on a uniform batch before deciding.
Suggested fix or plan change: either return an n × nbatch matrix for a batch (as "diag" concatenates members) and make getparam! accept it, or keep member 1 and state in the docstring that this is by design.
- Dominant language
- Julia
- Stars
- 4
- Forks
- 0
- Avg merge
- 4h 1m
- Merged PRs (30d)
- 73
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- No contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from exanauts/SparseDirectSolver.jl
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
exanauts/SparseDirectSolver.jl#141 ·
Maintainers usually reply within 1 day
-
found-by-agent
Difficulty 4/5 3-5 days Newbie friendliness 18/100
exanauts/SparseDirectSolver.jl#138 ·
Maintainers usually reply within 1 day
-
found-by-agent
Difficulty 4/5 3-5 days Newbie friendliness 18/100
exanauts/SparseDirectSolver.jl#137 ·
Maintainers usually reply within 1 day
-
T31 — oneAPI and Metal extensions, allocation-free KA dense fallbacks (issues #112, #53)Possibly taken @dmaldona claimed this 11 days ago. Opentask
Difficulty 5/5 Over a week Newbie friendliness 12/100
exanauts/SparseDirectSolver.jl#118 ·
Maintainers usually reply within 1 day
-
task
Difficulty 4/5 3-5 days Newbie friendliness 20/100
exanauts/SparseDirectSolver.jl#117 ·
Maintainers usually reply within 1 day
All issues in exanauts/SparseDirectSolver.jl
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
JuliaGPU/GPUArrays.jl#837 ·
Maintainers usually reply within 2 days
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 68/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
bmad-sim/BeamTracking.jl#382 ·
Maintainers usually reply within 1 day