Fused "S" factor on the 78k KKT is 1.1x above the stock eps-perturbation response (T35 gate (b))

Open
  • Is something wrong?
#181 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
julia
Domain
performance

Research direction

Start with bench/ARCH-TUNING.md, TASKS.md, and the #177 table to understand gate (b) and the stock comparison. Then inspect _front_ldl_update! and _front_ldl_scale!, including the WPANEL/WTILE paths where pivots are folded into Ai; determine which step causes the 78k "S" offset and compare its rounding with stock LDLᵀ. Done means the gate passes under the agreed criterion, or the criterion is revised as proposed.

Written by the indexing model from the issue text.

Description

found-by-agent

Found while working on: T35 (#180; PR to follow from task/T35-deterministic-fused)

What: T35 restates the factor gate of bench/ARCH-TUNING.md (ground rule 1) as (a) bitwise run-to-run equality under deterministic_mode = 1 and (b) fused vs stock no larger than the stock path's response to an eps-level perturbation of A (the #177 table). With T35 the fused factorization is bitwise reproducible (the extend-add and the in-kernel wide tiles are ordered), so its fused-vs-stock delta is now a constant per matrix. On the 78k condensed KKT (pglib_opf_case78484_epigrids, n = 674562) factored as "S" that constant is 1.1e-7 (L; D 9.9e-10 in #177) against a stock eps-perturbation response of 9.8e-8: (b) fails by 1.1×, as it did at main (1.2–1.3e-7 there, #177's "about 1.2×"). Measured on an H200 (sm_90), FusedSolver default tuning, 20 refactorizations, info 0, backward error equal to the stock one per #177. Every other harness matrix passes (b) (78k "SPD" 1.4e-8 vs 3.6e-8; case118 / case1354 "S" 1.8e-8 / 2.6e-8 vs 5.5e-8 / 7.0e-8; the well-conditioned ones ≤ 1.3e-15). The offset is the systematic rounding of the fused no-pivot LDLᵀ kernels (_front_ldl_update!/_front_ldl_scale!, the WPANEL/WTILE LDL paths with the pivots folded into the Ai tile) against the stock LDLᵀ, not the arrival order (which T35 removed).

Why it is out of scope: T35 orders the sums; it does not change the LDLᵀ arithmetic, and its text says the "S" offset stays. No task in TASKS.md owns the fused LDLᵀ rounding. It does not block anything: MadNLP uses the fused "S" factor with the stock backward error (#177).

Suggested fix or plan change: either read (b) for "S" against the fused path's own eps-perturbation response (1.2e-7 on the 78k, #177) or the factor backward error, or find which fused LDL kernel step (pivot folding in WTILE/TILE, the in-panel d scaling) carries the offset and match the stock rounding there.

Dominant language
Julia
Stars
7
Forks
0
Avg merge
12h 41m
Merged PRs (30d)
46

Getting set up

  • No Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from exanauts/SparseDirectSolver.jl

All issues in exanauts/SparseDirectSolver.jl

Similar issues

More Julia issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.