<div dir="ltr"><p>Good afternoon cp2k developers,<br>Regarding the setup of my input for the PDOS calculation (including inter-electronic couplings through diabatization), I encountered an unusual convergence issue. As shown in the attached output file, the total energy appears to "diverge" at each SCF iteration.</p>
<p>To address this problem, I decided to modify the restart wavefunction by using a file generated with the <strong>PBE+U</strong> method, instead of one obtained from a standard <strong>PBE</strong> calculation, as done in a previous test (whose input file is also attached). However, the convergence issue still persists in the following calculation, even after including the Hubbard correction.</p><br> 1 OT DIIS 0.80E-01 1116.7 0.00070560 -7523.8402746160 -7.52E+03<br> 2 OT DIIS 0.80E-01 845.8 0.84880918 -7399.9632959908 1.24E+02<br> 3 OT DIIS 0.80E-01 727.7 0.01083311 -7523.3761323117 -1.23E+02<br> 4 OT SD 0.80E-01 701.8 0.00252773 -7524.0396643421 -6.64E-01<br> 5 OT SD 0.80E-01 818.3 5.64458633 -8429.2536789938 -9.05E+02<br> 6 OT DIIS 0.80E-01 781.6 42.41696498 150357.5229304259 1.59E+05<br> 7 OT DIIS 0.80E-01 699.7 0.00163231 -7523.9647079113 -1.58E+05<br> 8 OT DIIS 0.80E-01 748.6 0.00216618 -7523.9831087634 -1.84E-02<br> 9 OT DIIS 0.80E-01 721.1 0.39080499 -7500.7599672907 2.32E+01<br> 10 OT DIIS 0.80E-01 747.7 0.28233406 -7501.4764303905 -7.16E-01<br> 11 OT DIIS 0.80E-01 877.7 0.55308111 -7512.0745363284 -1.06E+01<br> 12 OT DIIS 0.80E-01 691.1 1.21327090 -7412.3714625557 9.97E+01<br> 13 OT SD 0.80E-01 813.6 0.85821890 -7738.5230298085 -3.26E+02<br> 14 OT SD 0.80E-01 713.3 28.28919426 81675.8244234667 8.94E+04<br> 15 OT SD 0.80E-01 899.3 23.78977717 83513.7146849657 1.84E+03<br> 16 OT DIIS 0.80E-01 851.4 31.26519000 78050.0229091394 -5.46E+03<br> 17 OT SD 0.80E-01 807.5 11.92609899 27155.5632307179 -5.09E+04<br><br>In this email, I attach both input and output files of my hybrid functional calc. According to your experience, what can be the source of the problem? Thanks again for your help.<br><br>Best regards,<br>Lorenzo Lagasco</div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">Il giorno mar 28 apr 2026 alle ore 17:20 Johann Pototschnig <<a href="mailto:pototschnig.johann@gmail.com">pototschnig.johann@gmail.com</a>> ha scritto:<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>You need to check you bindings / number of processes. </div><div><br></div><div>You request 52 processes. Does mpi use them? To make sure run with:</div><div> mpirun -n 52 ...</div><div><br></div><div>If you don't have the CPU's and increase the number of OMP threads then they are run on the same processor, which will slow down the calculation as you have seen. </div><div><br></div><div>You can also split between MPI and OPENMP:</div><div>mpirun -n 26 -c 2 --bind-to none .. </div><div><div>(The options might have different names depending on the MPI distribution). </div><br></div><div><br></div><div>Which splitting works the best depends on your system and on the type of computation. </div><div>In general more MPI processes require more memory as they have their copies, while openmp does not work over different nodes. </div><div>There is more MPI parallelization in CP2K, so this should work for most types of calculation. </div><div><br></div><div><br></div><br><div class="gmail_quote"><div dir="auto" class="gmail_attr">On Tuesday, April 28, 2026 at 4:30:01 PM UTC+2 Lorenzo Lagasco 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"><div>Ok, maybe I can test a bit more carefully the EPS_DEFAULT and EPS_ORB (I have already launched different tests for checking convergence on NGRIDS,CUTOFF and REL_CUTOFF). Meanwhile, this is my slurm submission script:<br>#!/bin/bash<br>#SBATCH --job-name=HSEO6<br>#SBATCH --nodes=1<br>#SBATCH --ntasks-per-node=52<br>#SBATCH --partition=taras2-6230r<br><br>module purge<br>module load cp2k/may2025-gnu14.2.0-openmpi4.1.6-psm211.2.230<br>export OMP_NUM_THREADS=1<br><br>mpirun cp2k.popt -i DYE+SLAB.inp -o DYE+SLAB.out<br><br><br></div>I tried to increase the number of OMP_NUM_THREADS from 1 to 2 or 3 and, as a result, the time required for each scf step is longer and longer. Moreover, I regulated the MAX_MEMORY in relation to the memory free of the node. </div><br><div class="gmail_quote"></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Il giorno mar 28 apr 2026 alle ore 16:00 Frederick Stein <<a rel="nofollow">f.s...@hzdr.de</a>> ha scritto:<br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Dear Lorenzo,</div><div>Are you sure that you need these tight cutoffs (EPS_DEFAULT and especially EPS_PGF_ORB)? Can you check how many integrals are recalculated (check the output file)? If they are, is it possible for you to increase MAX_MEMORY? How are you running CP2K (number of MPI ranks, number of OpenMP threads)?</div><div>Best,</div><div>Frederick</div><br><div class="gmail_quote"><div dir="auto" class="gmail_attr">Lorenzo Lagasco schrieb am Dienstag, 28. April 2026 um 15:43:45 UTC+2:<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"><div><div><div></div></div></div><div><div><div><div dir="auto"><div><div><p>Good afternoon everyone,</p>
<p>I am writing to ask for advice on how to improve the computational efficiency of an HSE06 calculation used to evaluate inter-state couplings between diabatic states in a slab–organic dye system (using the Kondov diabatization scheme, system containing 395 atoms). I have attached the input file for reference. In a preliminary test on a CPU-only machine (single node with 52 processors), a single SCF iteration takes approximately 30 minutes.</p>
<p>Any suggestions would be greatly appreciated.<br><br></p><p>Best regards</p><p>Lorenzo Lagasco</p></div></div></div></div></div></div><br><br></div>
</blockquote></div>
<p></p></blockquote></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
-- <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 rel="nofollow">cp2k+uns...@googlegroups.com</a>.<br>
To view this discussion visit <a href="https://groups.google.com/d/msgid/cp2k/439c2d51-5c6f-4fc9-be1b-1ff2884ab77an%40googlegroups.com?utm_medium=email&utm_source=footer" rel="nofollow" target="_blank">https://groups.google.com/d/msgid/cp2k/439c2d51-5c6f-4fc9-be1b-1ff2884ab77an%40googlegroups.com</a>.<br>
</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" target="_blank">cp2k+unsubscribe@googlegroups.com</a>.<br>
To view this discussion visit <a href="https://groups.google.com/d/msgid/cp2k/173b3016-1da9-4054-bf0c-df730349b6fcn%40googlegroups.com?utm_medium=email&utm_source=footer" target="_blank">https://groups.google.com/d/msgid/cp2k/173b3016-1da9-4054-bf0c-df730349b6fcn%40googlegroups.com</a>.<br>
</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 visit <a href="https://groups.google.com/d/msgid/cp2k/CAKRVyRu3baViRnDaMFMk1zbLJOV2Cv75YscCrwTohw3oPvb5jA%40mail.gmail.com?utm_medium=email&utm_source=footer">https://groups.google.com/d/msgid/cp2k/CAKRVyRu3baViRnDaMFMk1zbLJOV2Cv75YscCrwTohw3oPvb5jA%40mail.gmail.com</a>.<br />