<div dir="ltr">Dear Fabian,<div><br></div><div>Thanks for your advise. I forgot to clarify the time ejecution... my mistake. </div><div>The calculation runs for 5 or 7 minutes, and stops... the walltime for the calculation was set as 72hrs, then I do not believe this is the problem. Now I am running the same input in a littler cluster (different form the problematic crash) with 64 proc and 250GB RAM, and the calculation works fine (so so slow, 9 hr per scf step, but runs... the total RAM assigned for the ERI's is not sufficient but the problem is not appear)... It is no practical to use this little cluster, then I need to fix the problem in the big one, to use more RAM and more processors (more than 220 it is possible), but as the program does not show what is happening, I cannot tell anything to the cluster admin to recompile or fix the problem. :(</div><div><br></div><div>This is the output in the little cluster:</div><div><br></div><div> Step Update method Time Convergence Total energy Change<br> ------------------------------------------------------------------------------<br><br> HFX_MEM_INFO| Est. max. program size before HFX [MiB]: 1371<br><br> *** WARNING in hfx_energy_potential.F:605 :: The Kohn Sham matrix is not ***<br> *** 100% occupied. This may result in incorrect Hartree-Fock results. Try ***<br> *** to decrease EPS_PGF_ORB and EPS_FILTER_MATRIX in the QS section. For ***<br> *** more information see FAQ: <a href="https://www.cp2k.org/faq:hfx_eps_warning">https://www.cp2k.org/faq:hfx_eps_warning</a> ***<br><br> HFX_MEM_INFO| Number of cart. primitive ERI's calculated: 27043173676632<br> HFX_MEM_INFO| Number of sph. ERI's calculated: 4879985997918<br> HFX_MEM_INFO| Number of sph. ERI's stored in-core: 116452577779<br> HFX_MEM_INFO| Number of sph. ERI's stored on disk: 0<br> HFX_MEM_INFO| Number of sph. ERI's calculated on the fly: 4763533420139<br> HFX_MEM_INFO| Total memory consumption ERI's RAM [MiB]: 143042<br> HFX_MEM_INFO| Whereof max-vals [MiB]: 1380<br> HFX_MEM_INFO| Total compression factor ERI's RAM: 6.21<br> HFX_MEM_INFO| Total memory consumption ERI's disk [MiB]: 0<br> HFX_MEM_INFO| Total compression factor ERI's disk: 0.00<br> HFX_MEM_INFO| Size of density/Fock matrix [MiB]: 266<br> HFX_MEM_INFO| Size of buffers [MiB]: 98<br> HFX_MEM_INFO| Number of periodic image cells considered: 5<br> HFX_MEM_INFO| Est. max. program size after HFX [MiB]: 3834<br><br> 1 NoMix/Diag. 0.40E+00 ****** 5.46488333 -20625.2826573514 -2.06E+04<br></div><div><br></div><div>About the SCREEN_ON_INITIAL_P, I read that to use it, you need a very good guess (more than de GGA converged one) as for example the last step or frame from a GEO_OPT or MD... Is it really useful when the guess is the GGA wavefunction?</div><div>About the CUTOFF_RADIUS, I read that 6 or 7 it is a good compromise, and as my cell is approximately twice, I use the minimal image convention to decide the 8.62 number which is near the recomended (6 or 7). If I reduce it, does the computational cost diminish considerably?</div><div><br></div><div>Regards - Lucas</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El dom, 22 nov 2020 a las 12:53, <a href="mailto:fa...@gmail.com">fa...@gmail.com</a> (<<a href="mailto:fabia...@gmail.com">fabia...@gmail.com</a>>) escribió:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Dear Lucas,</div><div><br></div><div>cp2k was computes the four-center integrals during (or prior) to the first SCF cycle.
I assume the job ran out of time during this task For a system with more than 1000 atoms this takes a lot of time. With only 220 CPUs this could take several hours in fact.</div><div><br></div><div>To speed up the calculation you should use SCREEN_ON_INITIAL_P T and restart using a well converged PBE wfn. Other than that, there is little you can do other than assign the job more time and/or CPUs. (Of course, reducing CUTOFF_RADIUS 8.62 would help too but could negatively affect the result).</div><div><br></div><div>Cheers,</div><div>Fabian<br></div><br><div class="gmail_quote"><div dir="auto" class="gmail_attr">On Sunday, 22 November 2020 at 01:21:05 UTC+1 Lucas Lodeiro wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi all, <div>I need to perform a hybrid calculation with CP2K7.1, over a big system (+1000 atoms). I study the manual, the tutorials and some videos of CP2K developers to improve my input. But the program exits the calculation when the HF part is running... I see the memory usage on the fly, and there is no peak which explains the fail (I used 4000Mb with 220 processors).</div><div>The output does not show some explanation... Thinking in the memory, I try with a largemem node at our cluster, using 15000Mb with 220 processors, but the program exists at the same point without message, just killing the process. </div><div>The output shows a warning:</div><div><br></div><div> *** WARNING in hfx_energy_potential.F:591 :: The Kohn Sham matrix is not ***<br> *** 100% occupied. This may result in incorrect Hartree-Fock results. Try ***<br> *** to decrease EPS_PGF_ORB and EPS_FILTER_MATRIX in the QS section. For ***<br> *** more information see FAQ: <a href="https://www.cp2k.org/faq:hfx_eps_warning" rel="nofollow" target="_blank">https://www.cp2k.org/faq:hfx_eps_warning</a> ***<br></div><div><br></div><div>but I read this is not a very complicated issue, and the calculation has to continue and not crash</div><div>Also I decrease the EPS__PGF_ORB, but the warning and the problem persist. </div><div><br></div><div>I do not know if the problem could be located in other parts of my input... for example I use the PBE0-T_C-LR (I use PBC for XY), and ADMM. In the ADMM options, I use ADMM_PURIFICATION_METHOD = NONE, due to I read that ADMM1 is the only one useful for smearing calculations. </div><div><br></div><div>I run this system with PBE (for the first guess of PBE0), and there is no problem in that case.</div><div>Moreover, I try with other CP2K versions (7.0, 6.1 and 5.1) compiled into the cluster with (libint_max_am=6), and the calculation crash, but show this problem:</div><div><br></div><div> *******************************************************************************<br> * ___ *<br> * / \ *<br> * [ABORT] *<br> * \___/ CP2K and libint were compiled with different LIBINT_MAX_AM. *<br> * | *<br> * O/| *<br> * /| | *<br> * / \ hfx_libint_wrapper.F:134 *<br> *******************************************************************************<br><br><br> ===== Routine Calling Stack ===== <br><br> 2 hfx_create<br> 1 CP2K<br></div><div><br></div><div>It seems like this problem is not present in the 7.1 version, as the program does not show it, and the compilation information does not show LIBINT_MAX_AM value...</div><div><br></div><div>If somebody could give me some advice, I will appreciate it. :)</div><div>I attach the input file, and the output file for 7.1 version.</div><div><br></div><div>Regards - Lucas Lodeiro</div><div><br></div></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:cp...@googlegroups.com" target="_blank">cp...@googlegroups.com</a>.<br>
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/cp2k/96479ce2-d8a3-4ccf-b55c-0e935878f1c0n%40googlegroups.com?utm_medium=email&utm_source=footer" target="_blank">https://groups.google.com/d/msgid/cp2k/96479ce2-d8a3-4ccf-b55c-0e935878f1c0n%40googlegroups.com</a>.<br>
</blockquote></div>