Deer Bussy<div><br /></div><div>Your suggestions have been extremely helpful. I am now able to run this system on a 512GB HPC.</div><div>The running speed is acceptable to me, considering the large amount of computation involved. </div><div>Thank you very much for your help.<br /><br /></div><div>Best wishes.</div><div>Jiang</div><div class="gmail_quote"><div dir="auto" class="gmail_attr">在2024年9月19日星期四 UTC+8 21:33:29<Augustin Bussy> 写道：<br/></div><blockquote class="gmail_quote" style="margin: 0 0 0 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div>Hi Jiang,</div><div>I was able to run your input file on a 512G system, but I'd like to add a few comments:</div><div>1) I somehow missed the fact that you are running RI-HFX with K-points. In such a case, the choice of the RI metric is not crucial for performance (or memory usage), and the best course of action is to keep the default.</div><div>2) What really matters is the number of atoms in the unit cell, the diffuseness of the basis set, and the range of the HFX potential. There is not much you can do here, especially since you already use ADMM. The range of the HFX potential really matters, because this influences how many periodic images of your system need to be considered. Typically, this has a limited impact for 2D systems, because there should only be images along the XY axes. However, if the extent of the cell in the Z direction is too short, periodic images get involved as well. <b>I found that increasing the Z cell parameters from 20 Ang to 30 Ang speeds up the calculations by a factor 2</b>, because less images are needed.<br></div><div>3) Unless you reach a very high number of K-points (~1000), this has practically no impact on cost, and only a little on memory. You might as well use a denser grid than 3x3x1<br></div><div>4) I am not sure if your system is a metal. If it is not, you should avoid using Broyden mixing and smearing, as SCF convergence slows down.<br></div><div>5) While you can run this calculation on a single HPC node with 512G, this will be extremely slow. I highly recommand using more resources, and increasing the KP_NGROUPS keyword the the HF%RI section. This is not a small calculation you are attempting.</div><div><br></div><div>I invite you to read the paper written for the method: <a href="https://doi.org/10.1063/5.0189659" target="_blank" rel="nofollow" data-saferedirecturl="https://www.google.com/url?hl=zh-CN&q=https://doi.org/10.1063/5.0189659&source=gmail&ust=1727082107291000&usg=AOvVaw2mqMd6vqTmWXl0yaPLbmvO">https://doi.org/10.1063/5.0189659</a>, this might help you understand some of the points above.</div><div>I hope that helps. Best,</div><div>Augustin<br> </div><div class="gmail_quote"><div dir="auto" class="gmail_attr">On Wednesday 18 September 2024 at 16:54:17 UTC+2 yj jiang wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Thank you all very much for your help. A few days ago, I thought I had uploaded the output file here, but it seems that due to the large file size, the upload may not have been successful. I apologize for this.<br><br>Yesterday, I seemed to have found the reason. The supercomputing job system I am using has a memory allocation limit for each process, and this issue is not exclusive to cp2k jobs. I am now planning to set the maximum memory usage for cp2k to see if it resolves the problem.<br><br>Thank you again for your help!<br><br>Jiang<br><br><div><div dir="auto">在2024年9月17日星期二 UTC+8 15:33:33<Augustin Bussy> 写道：<br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Hi,</div><div>everything that Frederick mentioned is very relevant. Additionally, I'd like to add that the method was developed with small unit cells in mind. Your cell is quite large, and this might cause memory issues, although having a 2D material should help. I'll see if I am able to run it.</div><div>Best,</div><div>Augustin<br></div><br><div><div dir="auto">On Monday 16 September 2024 at 08:18:57 UTC+2 Frederick Stein wrote:<br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Due to my lack of experience, I can just guess from my knowledge on RI methods, the manual and what I was told by the developer. Please also consider the respective manual page: <a href="https://manual.cp2k.org/trunk/CP2K_INPUT/FORCE_EVAL/DFT/XC/HF/RI.html#CP2K_INPUT.FORCE_EVAL.DFT.XC.HF.RI" rel="nofollow" target="_blank" data-saferedirecturl="https://www.google.com/url?hl=zh-CN&q=https://manual.cp2k.org/trunk/CP2K_INPUT/FORCE_EVAL/DFT/XC/HF/RI.html%23CP2K_INPUT.FORCE_EVAL.DFT.XC.HF.RI&source=gmail&ust=1727082107291000&usg=AOvVaw0qvBuOy4zCCGW8FSTnTY_C">https://manual.cp2k.org/trunk/CP2K_INPUT/FORCE_EVAL/DFT/XC/HF/RI.html#CP2K_INPUT.FORCE_EVAL.DFT.XC.HF.RI</a> .<br></div><div>- Change RI_METRIC to TRUNCATED and CUTOFF_RADIUS in the &RI section to a value between 1.0 and 2.0 . Lower values improve sparsity, larger values increase accuracy. The shortrange Coulomb metric has a rather large range. If you would like to stick to it, set the OMEGA parameter of the &RI section to a value larger then 0.11 (let's say 1-10).<br></div><div>- Just for testing, try a single k-point.</div><div>- Try other values of MEMORY_CUT in &RI. Larger values (try 10) should decrease the block sizes. I do not really know how it works but it does have an effect on memory usage.</div><div>- Increase EPS_FILTER in &RI to a larger value (double-check later whether you have to decrease it again).</div><div>If nothing of my suggestions work and the developer of the feature does not chime in, it may be that you do not have enough memory.</div><div>Best,</div><div>Frederick<br></div><div><br></div><br><div><div dir="auto">Frederick Stein schrieb am Sonntag, 15. September 2024 um 18:42:31 UTC+2:<br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Hi,</div><div>I am not an expert with RI-HFX but I would try to run potentially cheaper settings first (single k-point, smaller basis sets, larger value of omega, identity metric). It may also help to have an CP2K output file or supplementary input/output file if you submit jobs with a scheduler like Slurm. If there is no function stack in the output file(s) given (either by the compiler or by CP2K), you could also add the keywords TRACE and TRACE_MASTER to your GLOBAL section.</div><div>Best,</div><div>Frederick<br></div><br><div><div dir="auto">yj jiang schrieb am Sonntag, 15. September 2024 um 18:13:42 UTC+2:<br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi, I'm calculating band structure for C3N4 with a Ni atom (attachment). I want to use HES06 + RI-HFX + ADMM. There is a "out of memory" error. How can I address this? Thx. a lot.<div><br></div><div>I can access a hpc with max memory of 512G.</div></blockquote></div></blockquote></div></blockquote></div></blockquote></div></blockquote></div></blockquote></div> <p></p> -- <br /> You received this message because you are subscribed to the Google Groups "cp2k" group.<br /> To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:cp2k+unsubscribe@googlegroups.com">cp2k+unsubscribe@googlegroups.com</a>.<br /> To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/cp2k/1450b32b-3522-4e79-a93f-17b236e093d4n%40googlegroups.com?utm_medium=email&utm_source=footer">https://groups.google.com/d/msgid/cp2k/1450b32b-3522-4e79-a93f-17b236e093d4n%40googlegroups.com</a>.<br />