Repository navigation
Conversation
…ch, as a capability guide The three rulings (the base is never cut or rebalanced; one hierarchy carries the fault as the model has it; the placed ribbon serves both realisations), the fault-patch design as it ships on development with the iteration counts to expect and the configuration rules learned from failures, where parallel imbalance comes from, and the split-level hierarchy measured on feature/fault-split-multigrid but not merged. The two design documents it draws on gain status lines; the guide joins the capability-guide table and the toctree. Underworld development team with AI support from Claude Code
…dder with a hand-built chain Underworld development team with AI support from Claude Code
…t by vertices Underworld development team with AI support from Claude Code
Underworld development team with AI support from Claude Code
… base is never modified Underworld development team with AI support from Claude Code
The index table keeps both guide rows (fault multigrid, faults in convection). Underworld development team with AI support from Claude Code
…patch on the split finest level (ruling of 2026-11-01) The fault-multigrid guide drops the chain as what production runs and states the ruled tail with its counts from the tail sweep on #912's build; its configuration rule on the blocks now says FAC blocks are LU and records that the rotated path ran them as ILU(0) from 2026-09-03 until #912 (#892). The split-level section says the library merged (#889, #890) and keeps the chain as the measured alternative. Mesh.multigrid_levels (#915) replaces the private accessor. The faults-in-convection guide's hierarchy section, code and table are rewritten to the welded tail, with the chain labelled as the alternative and the ILU-era table retired to the journal. The guide is added to the developer toctree it was missing from. Underworld development team with AI support from Claude Code
|
Updated 2026-11-01 after Louis's ruling on #892 (issuecomment-6550186134) and the merges of #889, #890, #912 and #915.
Sphinx builds clean on the branch (exit 0, no warnings on the changed pages). Journal: the decision and finding entries of 2026-11-01 on the fault-multigrid topic. Generated by Claude Code |
…est patch sits on one rank Both guides cite kaiju's production annulus at np 16 beside the UWTN 2026-022 fixtures (5.9 against 7.7 velocity iterations per Newton increment, the same answers, both arms the same patch) and say the drivers' default moves to 0 with the campaign builds. The parallel section of the fault-multigrid guide records that the whole patch, 465 rows and 105 split pairs, is on one rank, so its LU solve is serial there (#895). Underworld development team with AI support from Claude Code
The two tails do the same velocity work on the production annulus (8.65 against 8.74 F-cycles per solve) in the same time within the run-to-run spread; the welded arm carries a 3584-row patch on one rank and the chain none, so the earlier reading of a smaller patch shared by both arms is withdrawn. The parallel section gives the patch's measured cost (21 to 28 s a step on one rank, 5 to 6 per cent of the solve) and says the structural patch is one block per rank with no row cap, the 2000-row cap being for zone blocks only. Underworld development team with AI support from Claude Code
|
Correction pushed (see the latest commit): kaiju's budget of the np 16 annulus pair (#892, issuecomment-6552218825) supersedes the comment I cited yesterday. The welded arm carried a 3584-row patch on one rank and the chain none, the velocity work is equal (8.65 against 8.74 F-cycles per solve) and the times are a wash; the patch's serial LU costs 5 to 6 % of the solve. Both guides now say that, and the parallel section carries the measured cost and the block rule (one structural block per rank, no row cap; the 2000-row cap is for zone blocks). Sphinx still builds clean. Generated by Claude Code |
…t gain Both guides give the ratio where they said the reason was open: the production annulus runs at a band ratio of 3.9, below the smallest ratio in the sweep table, and the patch's gain appears from about 8 upward. Underworld development team with AI support from Claude Code
What changed: a new capability guide
docs/developer/guides/fault-multigrid.md(kind: guide, families Stokes and Stokes_Constrained), a row in the developer index's capability-guide table and the toctree, and**Status:**lines on the two design documents it draws on (fault-patch-multigrid-2026-08.md,fault-parallel-placement-2026-09.md). Documentation only; no code.Why: the fault-multigrid rulings (the base is never cut or rebalanced; one hierarchy carries the fault as the model has it; the placed ribbon serves both realisations) kept being re-derived in new sessions, and the only place they were written down was the wiki. The guide states them once, says what ships on
development(the fault-patch design: the Galerkin ladder plus the strong patch keyed on the fault physics, the iteration counts to expect, the configuration rules learned from failures, the width ruling), where parallel imbalance comes from, and names the split-level hierarchy measured onfeature/fault-split-multigridas pending rather than available. Every API name was checked againstdevelopment; the docs build renders the page with no new warnings. The provenance is the journal topic page it links.Checklist (UW3 Style Charter — docs/developer/UW3_STYLE_CHARTER.md)
level_*andtier_*markers (S8): not a bug fixmaybe_/try_/do_) and no commented-out code (S3, S4).array/mesh.X.coords— nowith ....access(...), nomesh.data(S7): no codepixi.toml/pixi.lockor other dependency changes riding in an unrelated PRUnderworld development team with AI support from Claude Code
Generated by Claude Code