SumK_LDA.find_mu very slow and sometimes crashes about triqs_0.x

[parcollet]

• The error is an mpi error. Maybe a bug in the parallelisation of the sum ?
  Does the pb appear in any serial computation ?
• Indeed, the invert/multiply of local Green function was temporary put back in python for technical details,
  we have to move this loop to C++. The tests I made were less severe.

[aichhorn]

This problem that mpi crashes happened to me only on Weiss, nowhere else (and I used quite some clusters by now). The implementation of the SumK.find_mu did not change since 1.5 years at least, so there should not be the problem. Anyway, here at my cluster (using TRIQSv0.8) this find_mu is quite fast. Take the following case:

Dichotomy adjustment of Chemical_Potential to obtain Total Density = 64.000001 +/- 0.000100
Chemical_Potential = 0.500000
Total Density = 70.211073
0.000000 < Chemical_Potential < 0.500000
63.985668 < Total Density < 70.211073
0.001151 < Chemical_Potential < 0.500000
63.997105 < Total Density < 70.211073
0.001384 < Chemical_Potential < 0.500000
63.999425 < Total Density < 70.211073
0.001430 < Chemical_Potential < 0.500000
63.999887 < Total Density < 70.211073
0.001439 < Chemical_Potential < 0.500000
63.999978 < Total Density < 70.211073
Chemical_Potential found in 5 iterations :
Total Density = 63.999978;Chemical_Potential = 0.001439

This is a calculation with approximatly 50 bands in the projection window (i.e. size of the GF matrices), 165 k-points in the k-sum in the IBZ. The sum was split to 16 cores, and the calculation took 4 minutes. Typically I would go to 64 cores, so the time would be roughly 1-2 minutes, negligible compared to the Solver time.
By the way, I linked to MKL libraries when compiling TRIQS.

How long is the calculation time in your case, can you give some numbers? If you have a lot of bands in the projection, the time goes down quite rapidly (N^3 scaling)...

[lvboehnke]

Building numpy with icc and against mkl instead of the ubuntu repository version makes a difference of roughly 10-20% for me for the k-sums of simple cases. I really mean only the installation of numpy, triqs was in both cases build with icc and mkl. I can very well imagine that the effect on runtime becomes more extreme for larger problems...

[vanroeke]

For a calculation with approximately 20 bands in the projection window, 405 k-points and 64 cores, it took 10 minutes (7 iterations). I have been impatient there: it is not so bad eventually.

If the crash is a Weiss problem as you say then I guess the issue can be closed here.