subroutine "compute_max_radius" is taking about 1/4 of the total time of a geometry optimization

[Torstein Fjermestad]

Dear all, 

In a geometry optimization, the subroutine "compute_max_radius" is taking about 1/4 of the total time (see the first lines of the timing information below. "compute_max_radius" is shown in bold). 

What is "compute_max_radius" doing?

Is it normal that it takes that long time?

Is there anything one can do to reduce the time it takes?

Thanks in advance for your help.

Regards,

Torstein Fjermestad

SUBROUTINE	CALLS	ASD		SELF TIME		TOTAL TIME
	MAXIMUM		AVERAGE	MAXIMUM	AVERAGE	MAXIMUM
CP2K	1	1.0	0.560	0.562	880.431	880.44
cp_geo_opt	1	2.0	0.060	0.060	632.220	632.22
geoopt_bfgs	1	3.0	0.174	0.180	632.160	632.16
cp_eval_at	35	4.0	0.036	0.078	627.687	627.71
qs_forces	34	5.0	0.113	0.118	614.752	614.76
qs_energies	35	6.0	0.012	0.015	565.518	565.55
scf_env_do_scf	35	7.0	0.002	0.005	381.893	381.90
scf_env_do_scf_inner_loop	164	8.0	0.028	0.032	260.120	261.02
qs_init_subsys	1	2.0	0.406	0.408	245.615	245.62
qs_env_setup	1	3.0	0.043	0.043	244.914	244.92
qs_env_rebuild_pw_env	70	6.5	0.069	0.070	244.794	244.80
pw_env_rebuild	1	5.0	0.092	0.129	244.709	244.71
compute_max_radius	1	6.0	232.268	244.451	232.268	244.45
rebuild_ks_matrix	198	9.5	0.001	0.001	198.294	198.45
qs_ks_build_kohn_sham_matrix	198	10.5	0.078	0.082	198.293	198.45
qs_ks_update_qs_env	199	9.0	0.002	0.002	159.038	159.18
qs_energies_init_hamiltonians	35	7.0	0.033	0.034	151.114	151.13
build_qs_neighbor_lists	35	8.0	0.187	0.212	100.828	136.07
init_scf_loop	35	8.0	0.001	0.002	120.711	120.72
pw_transfer	4199	13.3	0.347	0.410	93.912	95.354

 

[Krack Matthias (PSI)]

Hi Torstein

 

That’s indeed surprising. I never saw compute_max_radius coming up in the timing statistics. You will have to provide the case causing that behavior in case you expect a feedback from this forum.

 

Matthias

--
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/2bf88680-8dec-478a-9904-e63ced6dc1d7%40googlegroups.com.

[Tiziano Müller]

Hi Torstein,

as Matthias pointed out, we would have to know more about your use case
(used basis set in particular) to be able to help.

You might also want to try https://github.com/cp2k/cp2k/pull/444 if
that's not possible for some reason (simply add `.patch` to the URL to
get a patch file you can then apply).

Best regards,
Tiziano

> *compute_max_radius *
> *           1 * *6.0 * *232.268 * *244.451 * *232.268 * *244.45*

>  rebuild_ks_matrix
> 198 9.5   0.001   0.001 198.294 198.45
>  qs_ks_build_kohn_sham_matrix
>        198 10.5   0.078   0.082 198.293 198.45
>  qs_ks_update_qs_env
> 199 9.0   0.002   0.002 159.038 159.18
>  qs_energies_init_hamiltonians
> 35 7.0   0.033   0.034 151.114 151.13
>  build_qs_neighbor_lists
>          35 8.0   0.187   0.212 100.828 136.07
>  init_scf_loop
>          35 8.0   0.001   0.002 120.711 120.72
>  pw_transfer
>        4199 13.3   0.347   0.410  93.912  95.354
>

> --
> 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

> <mailto:cp2k+uns...@googlegroups.com>.

> To view this discussion on the web visit
> https://groups.google.com/d/msgid/cp2k/2bf88680-8dec-478a-9904-e63ced6dc1d7%40googlegroups.com

> <https://groups.google.com/d/msgid/cp2k/2bf88680-8dec-478a-9904-e63ced6dc1d7%40googlegroups.com?utm_medium=email&utm_source=footer>.

--
Tiziano Müller
University of Zurich
Department of Chemistry
Winterthurerstrasse 190
CH-8057 Zürich

Tel: +41 44 63 54234
www.chem.uzh.ch
tiziano...@chem.uzh.ch

[Torstein Fjermestad]

Dear Matthias and Tiziano,

thanks for your reply, and please find attached the cif file of the structure, the cp2k output file, and the restart file. 

The atom-centered basis set is DZVP-MOLOPT-SR-GTH for all atoms, and the plane wave cut-off is 360 Ry. 

Please tell me if you need any further information. 

Thanks for your help. 

Regards,

Torstein

[hut...@chem.uzh.ch]

Hi

the problem is related to the CIF file or reading the CIF file.
It defines atoms as O1, O2, ... and CP2K generates a different atomic kind
for all atoms. This then needs 289 basis set initializations (instead of 4).

You can either delete the numbers after the atomic symbol in your CIF file,
or switch to CP2K 7.1 where this has been solved by using a smarter parsing
of the CIF file.
In both cases the time for compute_max_radius should be rediced by a factor 50.

regards

Juerg
--------------------------------------------------------------
Juerg Hutter Phone : ++41 44 635 4491
Institut für Chemie C FAX : ++41 44 635 6838
Universität Zürich E-mail: hut...@chem.uzh.ch
Winterthurerstrasse 190
CH-8057 Zürich, Switzerland
---------------------------------------------------------------

-----cp...@googlegroups.com wrote: -----
To: "cp2k" <cp...@googlegroups.com>
From: "Torstein Fjermestad"
Sent by: cp...@googlegroups.com
Date: 01/10/2020 05:52PM
Subject: [CP2K:12757] Re: subroutine "compute_max_radius" is taking about 1/4 of the total time of a geometry optimization

--
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/13571979-d62a-4626-94fd-fa1418c18b40%40googlegroups.com.


[attachment "files-for-cp2k-forum.zip" removed by Jürg Hutter/at/UZH]

[Krack Matthias (PSI)]

Hi Torstein

 

Why do you have an atomic kind for each atom? Do you have any specific reason for that choice? You have 289 atoms and 289 atomic kinds, but 3 kinds (H, O, Si) would do. Try to remove the numbers from the element labels in COORD section. “compute_atomic_kind” is called to calculate the interaction radii for Gaussian functions of each atomic kind. This is most likely the reason for the timings.

BTW, I wouldn’t use CP2Ks .restart files as input files.

 

HTH

 

Matthias

 

From: cp...@googlegroups.com <cp...@googlegroups.com> On Behalf Of Torstein Fjermestad

Sent: Freitag, 10. Januar 2020 17:53
To: cp2k <cp...@googlegroups.com>

--

[Torstein Fjermestad]

Dear Juerg, 

Thanks a lot for your help. I removed the numbers in the atom labels, and the total time of the calculation went down from 880.44s to 483.034s. 

Dear Matthias, 

There is no specific reason for having an atomic kind for each atom. I generated the cif file with an ASE script, and the numbers were added to the atom lables. Now that I am aware of the issue, I will delete the numbers from the atom label before I use the cif file in a calculation. 
My input files contain a lot of if clauses and @include statements. I posted the .restart file because I thought that it might be easier to understand what keywords I had used. Now I realize that it might have caused unnecessary confusion. 

Regards,

Torstein

onsdag 8. januar 2020 17.59.54 UTC+1 skrev Torstein Fjermestad følgende:

[Hans Pabst]

The CP2K/master accelerated compute_max_radius computations. This discussion pointed out the root cause of compute_max_radius being a hotspot (because of unnecessary/duplicated atomic kinds). However, the restart/input file attached earlier improved by ~1.7x (wall time) when comparing current CP2K/master vs. CP2K at the point of this discussion.