Timing reports after job execution

[ziand]

Hello.

When an ATK-Job is finished, there is always a timing-report. I noticed, that the sum of timings is often far below 100%.
For example:
Timing:                          Total     Per Step        %
--------------------------------------------------------------------------------
Density Matrix (EQ)     :    7445.76 s     148.92 s      17.40% |========|
Transmission Spectrum   :    4647.48 s     929.50 s      10.86% |====|
Real Space Density      :    1049.96 s       4.20 s       2.45% ||
Self-Energies           :     128.05 s       2.56 s       0.30% |
Diagonalization         :      91.14 s      18.23 s       0.21% |
Hartree Potential       :      24.08 s       0.10 s       0.06% |
Setting Density Matrix  :       2.86 s       0.57 s       0.01% |
Mixing                  :       0.09 s       0.00 s       0.00% |
Laplace Kernel          :       0.02 s       0.00 s       0.00% |
Density Matrix (NEQ)    :       0.00 s       0.00 s       0.00% |
--------------------------------------------------------------------------------
Total                   :   42802.05 s (11h53m22.05s)

After a closer look, I think that some (?) of the timing results printed at the end of a job are those from the LAST SCF-calculation while others maybe for the whole job. To clearify: There is a simple loop inside my script that does 5 repeated TransmissionSpectrum-calculations and the last calculation took 50 steps.
Density Matrix (EQ): 148.92 * 50 = 7445.76  (time spent for last calculation???)
But
Transmission Spectrum: 929.50 * 5 = 4647.48  (time spent for ALL 5 calculations???)

Could you please commtent an those numbers?

It would be nice to have a command that can be called within an ATK-script to print such a timing-report (and maybe reset the times to zero afterwards), to have multiple reports within one log-file.

Thanks.

[Anders Blom]

You are probably right, the transmission is summed but the density matrix is only for the last calculation.

Once should not expect the sum of all parts to always be exactly 100% (sometimes it's even above) because it is very difficult to time exactly each part. The report is only meant to give a general idea about where the bottlenecks in the calculation are, this can help determine whether it would make sense to parallelize this job on more nodes, for instance.

However, the discrepancy should not be as large as that you observe, then it becomes useless. The reason is, as you have guessed basically, that the functionality for timing is intended for the case when you have one calculation in the script.

We'll have a look at how we can improve this functionality for more general cases.