[WIP] cache Least Squares matrix for gradient computation - #2871
Draft
tbellosta wants to merge 3 commits into
Draft
[WIP] cache Least Squares matrix for gradient computation#2871tbellosta wants to merge 3 commits into
tbellosta wants to merge 3 commits into
Conversation
Member
|
Nice. Make it the default, compute in geometry preprocessing when necessary, no opt-in |
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
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.
Proposed Changes
This PR
adds an opt-in option,caches the factorized metric terms of the (weighted or unweighted) least-squares gradients. The LSQ normal matrix A depends only on the node coordinates and on the weighting, yet it is currently re-assembled and re-factorized on every gradient evaluation, every nonlinear iteration. With the option enabled:CACHE_LSQ_METRICS(defaultNO),CGeometry.SetControlVolume(..., UPDATE)(the common point of all mesh motion/deformation paths, on fine and coarse MG levels) and rebuilt on the next evaluation, i.e. once per mesh update, so the savings scale with the number of inner iterations per time step.Saved operations (per node per gradient evaluation, 3D, k edge-neighbors, N variables)
Eliminated from every evaluation after the first:
What remains is the RHS accumulation (~4N flops per node per edge) and one S*b product (18N flops per node). For the N=6 compressible primitives this roughly halves the gradient-kernel flops; for scalar solvers (N=1-2, e.g. SA) where the assembly dominates it is a ~4-5x reduction. Measured end-to-end (serial, linear-solver work held fixed): ~3.3% of total wall time on an inviscid ONERA M6 (57.5k nodes, tets, one gradient set per iteration) and ~6% on a 2D RANS-SA case (three LSQ gradient sets per iteration). Cases dominated by the linear solver will see proportionally less.
Memory footprint
The cache adds nDim*(nDim+1)/2 su2doubles per node per weighting used (48 B/node per weighting in 3D, 24 B/node in 2D; at most two weightings), allocated lazily per grid level and shared by all solvers. For reference, every solver already allocates an nDim*nDim
Rmatrixscratch (72 B/node in 3D), so for a typical RANS case the addition is small compared to the existing gradient machinery and negligible compared to overall solver memory.Validation
With the option enabled, results are identical to
develop(to output precision) for:NUM_METHOD_GRAD= WEIGHTED_LEAST_SQUARESandNUM_METHOD_GRAD_RECON= LEAST_SQUARES(all residuals including the turbulence variable),GRID_MOVEMENT= RIGID_MOTION(dual time stepping), exercising the invalidation/rebuild path,config_template.cfgdocuments the new option. Default behavior (CACHE_LSQ_METRICS= NO) is bit-identical to current develop.pre-commit run --allto format old commits.