[CP2K-user] [CP2K:19110] Re: diamond with TC-LRC + ADMM very slow

[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

From: cp2k at googlegroups.com <cp2k at googlegroups.com> on behalf of Martin Konôpka <konopka2010 at gmail.com>
Date: Thursday, 13 July 2023 at 18:29
To: cp2k at googlegroups.com <cp2k at googlegroups.com>
Subject: Re: [CP2K:19108] Re: diamond with TC-LRC + ADMM very slow
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 <cp2k at googlegroups.com<mailto:cp2k at googlegroups.com>> napísal(a):
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 schrieb am Donnerstag, 13. Juli 2023 um 11:49:05 UTC+2:
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.
--
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+unsubscribe at googlegroups.com<mailto:cp2k+unsubscribe at googlegroups.com>.
To view this discussion on the web visit https://groups.google.com/d/msgid/cp2k/769754fc-99e7-4489-8836-9d3b500de62bn%40googlegroups.com<https://groups.google.com/d/msgid/cp2k/769754fc-99e7-4489-8836-9d3b500de62bn%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
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+unsubscribe at googlegroups.com<mailto:cp2k+unsubscribe at googlegroups.com>.
To view this discussion on the web visit https://groups.google.com/d/msgid/cp2k/CAE0%3D32bVbf9%3Dui1seDiFs8Rsuvbn6zmdfdDVUJR9BW%3DrSQgjUA%40mail.gmail.com<https://groups.google.com/d/msgid/cp2k/CAE0%3D32bVbf9%3Dui1seDiFs8Rsuvbn6zmdfdDVUJR9BW%3DrSQgjUA%40mail.gmail.com?utm_medium=email&utm_source=footer>.

-- 
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+unsubscribe at googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cp2k/ZRAP278MB08273AAA4AAC402EE579BB16F434A%40ZRAP278MB0827.CHEP278.PROD.OUTLOOK.COM.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cp2k.org/archives/cp2k-user/attachments/20230714/ccb5f480/attachment-0001.htm>