move EffDiff setupMatrixEquation/generateActiveMask to public section#271
Merged
jameslehoux merged 1 commit intomasterfrom May 6, 2026
Merged
move EffDiff setupMatrixEquation/generateActiveMask to public section#271jameslehoux merged 1 commit intomasterfrom
jameslehoux merged 1 commit intomasterfrom
Conversation
CUDA build of openimpala-cuda failed in 6ea391c with three nvcc errors: error: The enclosing parent function ("generateActiveMask") for an extended __device__ lambda cannot have private or protected access within its class The pre-existing LoopOnCpu calls compiled fine because they don't use extended __device__ lambdas. My new ParallelFor / ReduceOps::eval calls do, and the CUDA Programming Guide §I.4.1 forbids that inside private or protected member functions: nvcc cannot emit the necessary internal linkage for the lambda's hidden context capture. TortuosityHypre.H already exposes setupMatrixEquation, initializeDiffCoeff, buildTraversableMask, preconditionPhaseFab as public for exactly this reason (line 159+). Match that pattern for the EffDiff equivalents: move setupMatrixEquation and generateActiveMask out of `private:` and into the public section, with a comment explaining the constraint. These methods aren't part of any user-facing API — the EffectiveDiffusivityHypre class is consumed via solve() / value() / getChiSolution() — so widening their visibility has no semantic impact, only relaxes the visibility on internal helpers that user code shouldn't be calling anyway. https://claude.ai/code/session_011dJ5Bwq4Tnr8wxH597XJFf
Performance Benchmark Results
Fastest solver: bicgstab at 64³ (0.3963s) Benchmark: uniform block (analytical τ = (N-1)/N) |
Code Coverage ReportGenerated by CI — coverage data from gcovr |
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
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
1 participant
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.
CUDA build of openimpala-cuda failed in 6ea391c with three nvcc errors:
The pre-existing LoopOnCpu calls compiled fine because they don't use extended device lambdas. My new ParallelFor / ReduceOps::eval calls do, and the CUDA Programming Guide §I.4.1 forbids that inside private or protected member functions: nvcc cannot emit the necessary internal linkage for the lambda's hidden context capture.
TortuosityHypre.H already exposes setupMatrixEquation, initializeDiffCoeff, buildTraversableMask, preconditionPhaseFab as public for exactly this reason (line 159+). Match that pattern for the EffDiff equivalents: move setupMatrixEquation and generateActiveMask out of
private:and into the public section, with a comment explaining the constraint.These methods aren't part of any user-facing API — the EffectiveDiffusivityHypre class is consumed via solve() / value() / getChiSolution() — so widening their visibility has no semantic impact, only relaxes the visibility on internal helpers that user code shouldn't be calling anyway.