[WIP] Reduce extra memory usage in scGW and GW+EDMFT workflows - #49
Draft
weiyiguo9 wants to merge 8 commits into
Draft
[WIP] Reduce extra memory usage in scGW and GW+EDMFT workflows#49weiyiguo9 wants to merge 8 commits into
weiyiguo9 wants to merge 8 commits into
Conversation
Stream large distributed-array redistributions through bounded peer tiles instead of allocating full send and receive pack buffers. Cap shared-array all-reduce chunks by bytes and add MPI regression coverage for layouts, scaling, and multi-node reductions.
weiyiguo9
marked this pull request as draft
August 11, 2026 10:38
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.
Important
Work in progress. Implementation validation and memory profiling are still ongoing.
Goal
Eliminate avoidable extra and peak memory usage throughout the GW and EDMFT workflows, especially for large distributed calculations where MPI communication can create substantial temporary allocations.
Main changes
Status
This PR is still under active development. Focused regression tests have been added, but end-to-end GW and EDMFT workflow validation and memory profiling are not yet complete.
Current capacity milestone
Preliminary WIP result: an SrVO3 calculation with a 10x10x10 k-point grid and 300 bands can currently run within the following regular-node allocation:
For context, the current Snellius
genoapartition provides 192 CPU cores and 336 GiB of allocatable RAM per node. The underlying regular Genoa node has two 96-core AMD EPYC 9654 processors at 2.4 GHz, 384 GiB of physical DDR5 memory, and ConnectX-7 NDR networking (200 Gbps within a rack and 100 Gbps across racks). See the official Snellius partition documentation and hardware documentation.This records the current runnable memory envelope only. End-to-end validation, memory profiling, scaling measurements, and scientific acceptance are still in progress.