Comment 5 for bug 1834949

Dear Mr. Papior,

thank you, this clarifies alot !!

.. It is quite counterintutive that a flag with name
"SCF.Mix.First"
does enable to actually *not* mix the first step if it is set to true together with a small weight.linear. Ok, i will try it now with the modifications.

Indeed, with "coefficient = 0" i meant the mixing weight. I have set it to 0.00 in the 24-unit calculations, thus expected no change. I was not aware that this is separate from the initial mixing. The 0.3 was not used in SOC for the large systems, only for the 6-unit calculation.

Regarding the "this should not happen" : Now it is clear based on your explanation that the code does change the initial state and therefore probably diverges. I dont have these files anymore, unfortunately, but it should be clear after the tests.

I have looked into ELPA and had written to our IT, because its installation seems to require some nontrivial steps for the compilation. But it is very nice that the code comes with these capabilities.. also MRRR (which did not give a significant speedup however, but maybe due to other reasons).
The speedup from 40*24 to 80*24 cores, within expert mode, was nearly linear, meaning it achieved twice as many cycles. After that, the scaling is bad though (the IT suggested to use even more cores but this quickly showed to be inefficient for this system, with limited number of orbitals).

If the restart works, this number can be reduced. I just tried to get enough cycles in 1 day to somehow get over the jump..

Thank you again !
Hopefully the data will support this