diamond with TC-LRC + ADMM very slow

[Martin Konôpka]

Dear CP2K experts,

I tried to use PBE0 functional with the TC-LRC + ADMM technique to calculate bulk diamond in a (110)-oriented cell. First however I used PBE (with the same grids etc) to produce a good initial guess for wavefunctions. The PBE calculation on 14 cores took about 249 sec per electronic iteration. Then I started PBE0 on 18 cores. It took 9909 sec (the 2nd iteration), which is unexpectedly long time. You can see attached my I/O files. BTW, concurrently with the PBE calculation, another calculation was running on the remaining 4 cores of the machine. Without that additional load and using all 18 cores, the time would drop to 194 sec only (PBE).

I have a some experience with using the TC-LRC + ADMM technique for TiO2 systems and also for some organic molecules. In those cases PBE0 was always just about 2-3 times slower than PBE. Now I see the enormous ratio and do not understand the reason.

Also, I was surprised by huge memory consumption by the PBE0 calculation: Over 200 GB in total. Still, it fit in the available memory (256 GB DDR4)  and the machine remained perfectly responsive. Isn't there some problem with the basis sets that I used for carbon?

The cp2k version that I used was 9.1, the "factory" one provided by the package manager on ubuntu 22.04. I am using also Intel MKL installed through the package manager. I launched the calculation in a screen session by the command

     mpirun -np 18 cp2k.popt -i cp2k.inp -o cp2k.out

The machine is a single-socket one with hyperthreading off.

Thanks for your opinions and for your work on bulding the CP2K code.

Sincerely

Martin Konôpka.

[Frederick Stein]

Dear Martin,

From your PBE0 output file, I see that most integrals are calculated on the fly indicating that your machine does not have enough memory to store all integrals. This increases the compute time significantly. What you could try is to

1) replace the pFIT3 with the cpFIT3 basis set to reduce the number of contracted basis functions

2) increase the EPS_DEFAULT parameter to reduce the number of matrix elements and number of integrals to calculate (only if your accuracy demands are still met)

HTH,

Frederick

[Martin Konôpka]

Dear Frederick,

Thanks. You are right, there were too many integrals to do on the fly. I checked some of my previous calculations with the PBE0 TC-RLC + ADMM techniques (a TiO2 rutile system) and I see there were zero integrals to do on the fly in those jobs (on the same machine). That's a pretty difference. Unfortunatelly, with diamond even switching to cpFIT3 and releasing EPS_DEFAULT to 10^{-11} (by three orders of magnitude) did not help. After almost three hours even the 1st electronic iteration was not over (or at least no writing produced) and I stopped the job. A much more radical truncation and/or optimisation of the basis sets would be needed. At least for now, I am going to abandon PBE0 and use just PBE for this diamond system. And it looks that for PBE, plane waves with ultrasoft pseudopotentials are a much faster approach for this (rather dense) material. (I did a quick test today with the CPMD code using a 35 Ry PW cutoff.)

Best wishes

Martin.

št 13. 7. 2023 o 13:17 'Frederick Stein' via cp2k <cp...@googlegroups.com> napísal(a):

--
You received this message because you are subscribed to the Google Groups "cp2k" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cp2k+uns...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cp2k/769754fc-99e7-4489-8836-9d3b500de62bn%40googlegroups.com.

[Krack Matthias]

Dear Martin

 

You are using a TZV2P basis set for C with a very small exponent of 0.03 causing large interaction ranges which lets the number of integrals in a (dense) periodic system like diamond explode. I suggest to try the DZVP-MOLOPT-PBE0-GTH-q4  or TZV2P-MOLOPT-PBE0-GTH-q4 basis set from the file BASIS_SET_UZH with PBE0 instead. For PBE I suggest to try the (default) DZVP-MOLOPT-SR-GTH-q4 basis set from BASIS_MOLOPT.

 

HTH

 

Matthias

 

To view this discussion on the web visit https://groups.google.com/d/msgid/cp2k/CAE0%3D32bVbf9%3Dui1seDiFs8Rsuvbn6zmdfdDVUJR9BW%3DrSQgjUA%40mail.gmail.com.

[Martin Konôpka]

Dear Matthias,

Thanks, I tried to use some of the basis you suggested. Namely the DZVP-MOLOPT-PBE0-GTH-q4 one. I found it file BASIS_MOLOPT_UZH. (You likely meant this one, not BASIS_SET_UZH, as there is no such a one in /usr/share/cp2k/ .) For simplicity, I used it for both PBE and PBE0 calculation. (The PBE one served just to produce an intial guess and I wanted to use the same basis set for both PBE and PBE0 calculations.) Unfortunately, the number of integrals to do on the fly even increased.  You can look my files in attachment. It looks that diamond is tough not only mechanically, but also to calculate with standard basis sets. I have not tried yet a carbon basis with the "SR" string. I think I will try such a one.

Best wishes

Martin.

pi 14. 7. 2023 o 9:49 Krack Matthias <matthia...@psi.ch> napísal(a):

To view this discussion on the web visit https://groups.google.com/d/msgid/cp2k/ZRAP278MB08273AAA4AAC402EE579BB16F434A%40ZRAP278MB0827.CHEP278.PROD.OUTLOOK.COM.

[S Ling]

Hi Martin,

It is known that for diamond, the condition number of the overlap matrix with the FIT3 basis is unfavorable, see Section 3.6 of the original paper on ADMM, https://pubs.acs.org/doi/full/10.1021/ct1002225. For this, the authors of the ADMM paper developed an optimised ADMM basis, i.e. optFIT3, for C, but this basis was not supplied in the SI of the paper or uploaded into the CP2K basis library. Prof Hutter mentioned he cannot find that basis in a previous post, see https://lists.cp2k.org/archives/cp2k-user/2020-May/013397.html.

Best regards,

SL

[Augustin Bussy]

Dear Martin,

in dense systems where calculating the integrals on the fly is a major bottleneck, the RI-HFX method can be more performant. I suggest you run some tests with

&RI

   RI_METRIC IDENTITY

&END RI  

added to your input &HF section, and

SORT_BASIS EXP

added to the &DFT section. Since you also run on a small number of processors, you might want to reduce memory usage by setting the MEMORY_CUT keyword in the &RI section to 4 or 5.

For more information on the method, see the manual: https://manual.cp2k.org/trunk/CP2K_INPUT/FORCE_EVAL/DFT/XC/HF/RI.html, or the paper discussing the implementation: https://pubs.aip.org/aip/jcp/article/158/16/164109/2886896.

Best,

Augustin

---

From: cp...@googlegroups.com <cp...@googlegroups.com> on behalf of S Ling <lingsa...@gmail.com>
Sent: Sunday, July 16, 2023 12:23 AM
To: cp2k <cp...@googlegroups.com>
Subject: Re: [CP2K:19115] Re: diamond with TC-LRC + ADMM very slow

 

To view this discussion on the web visit https://groups.google.com/d/msgid/cp2k/38543586-6f57-4a09-ad8e-a9436a2b3f7an%40googlegroups.com.

[Martin Konôpka]

Dear S Ling, dear Augustin,

Thanks for your quite instructive advices.

Best

Martin.

po 17. 7. 2023 o 10:24 Augustin Bussy <augusti...@chem.uzh.ch> napísal(a):

To view this discussion on the web visit https://groups.google.com/d/msgid/cp2k/GV0P278MB037087BD686FE8C351180385D33BA%40GV0P278MB0370.CHEP278.PROD.OUTLOOK.COM.