Conversation
hnil
added
the
manual:enhancement
hnil
marked this pull request as draft
August 7, 2026 15:35
hnil
force-pushed
the
pr/trueimpes-row-equilibration
branch
2 times, most recently
from
August 11, 2026 12:06
4459366 to
7b958f9
Compare
The 50e5 factor on the pressure row of block_transpose was a no-op in exact arithmetic: the rhs of the local solve is a unit vector, so scaling row p by s yields w = B^-T e_p / s, and the subsequent abs_max normalisation divides the factor straight back out. Its only effect was to condition the small dense solve, since the pressure row of a storage derivative is tiny relative to the others. Equilibrate all rows to unit max magnitude instead, with power-of-two factors so the scaling introduces no rounding. Same cancellation argument, no magic constant, and every row is conditioned rather than just the pressure one. Verified behaviour-neutral on SPE1CASE1 (trueimpes 383/322/445 -> 376/317/440; default cprw 443 -> 437 - pivoting noise). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Member
Author
|
jenkins build this please |
hnil
force-pushed
the
pr/trueimpes-row-equilibration
branch
from
September 18, 2026 07:26
7b958f9 to
400d4d9
Compare
bska
reviewed
Sep 18, 2026
| for (int jj = 0; jj < numEq; ++jj) { | ||
| double rowmax = 0.0; | ||
| for (int ii = 0; ii < numEq; ++ii) { | ||
| rowmax = std::max(rowmax, std::fabs(block_transpose[jj][ii])); |
Member
There was a problem hiding this comment.
Note: rowmax is a double here, whereas block_transpose[jj][ii] is the element type of a MatrixBlockType. If those two are not the same, then this statement will fail to compile since there is no overload of std::max() that accepts inputs of different types.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The 50e5 factor on the pressure row of the local trueimpes solve is a no-op in exact arithmetic: the rhs is a unit vector, so any row scaling cancels in the abs_max normalisation. Replace it with a power-of-two equilibration of all rows, which conditions the small dense solve without a magic constant.
Shows the effect (weights unchanged, so iteration counts move only at pivoting-noise level):
SPE1CASE1 cprw 443 -> 437 and SPE9_CP unchanged at 439; the trueimpes CPR path via an explicit JSON gives 383/322/445 -> 376/317/440.
🤖 Generated with Claude Code