<div dir="ltr">Dear CP2K developers,<br><br>I have started to benchmark CP2K on our clusters, and there are a few things that I don't</div><div dir="ltr">fully understand about the memory consumption of hybrid DFT calculations.<br><br>1. What needs to be considered in setting <a href="https://manual.cp2k.org/trunk/CP2K_INPUT/FORCE_EVAL/DFT/XC/HF/MEMORY.html#MAX_MEMORY" target="_blank">MAX_MEMORY</a>, so as to use as much RAM as possible?<br>MAX_MEMORY being the maximal amount of memory per MPI rank, in MiB, that the HFX module<br>is allowed to use.<br><br>At first, I thought it  would simply involve dividing the amount of RAM per (multi-core)<br>compute node by the number of MPI ranks per node, and then subtracting a modest amount<br>that will be needed by the rest of the program.<br><br>In the attached down-scaled version of the LiH-HFX benchmark, for example, the GGA prerun<br>on a 28-core node utilizes circa 250 MiB per MPI rank. In a subsequent HFX calculation<br>on the same node with MAX_MEMORY = 1500 MiB, the HFX module uses all of its allowed memory,<br>which is fine. But the job's total memory usage amounts to around 3000 MiB per MPI rank,<br>as given by CP2K's "max memory usage/rank" output and a check with "htop".<br><br>This is quite larger than the 1500+250=1750 MiB per MPI rank that I naively expected.<br>So is there a more sophisticated "rule of thumb" for predicting the total memory usage?<br><div>Or is this not even how CP2K is supposed to behave?</div><div><br></div><br>2. What should I expect from using multiple OpenMP threads per MPI rank in terms of memory<br><div>consumption? Suppose that MAX_MEMORY is such that 50% of the ERIs cannot be stored and</div><div>need to be (re)calculated on-the-fly, for OMP_NUM_THREADS=1. Suppose then that I set</div><div>OMP_NUM_THREADS=2, use half the number of MPI ranks, and double the MAX_MEMORY,</div><div>to arrive at the same memory usage by the HFX module. Should this then allow all ERIs to be</div><div>stored in memory?</div><div><br></div><br>Best,<br>Maxime<br></div>