Dear SIESTA users,
I am in process of assessing how well the parallel version of SIESTA 2.0.2
performs on our new cluster. To do so, I'm runing test jobs and monitoring
the timing of the jobs with different SIESTA and cluster-related inputs.
The test job I'm running is a (1x2) Si(100) slab geometry optimisation. The
system contains 64 atoms. Functional is PBE, mesh cutoff is 150 Ry, Kpoint
mesh is 4x2x1. The basis set is setted as
%Block PAO.Basis
Si 3 -0.46385
n=3 0 2 E 15.42551 4.96988
7.00000 4.37722
1.00000 1.00000
n=3 1 2 E 4.69636 3.83128
7.00000 4.09123
1.00000 1.00000
n=3 2 1 E 11.96912 0.03131
4.55426
1.00000
%EndBlock PAO.Basis
1- When I don't specify any BlockSize, SIESTA use a defautl value of 24 and
not 8 as stated in the user guide. Does anyone know the reason for that?
2- When trying different BlockSize options, I see that the scf convergence
is not the same for all jobs.
For exemple, for a 4 cpu job:
BlockSize 8: total run time is 15h54 - first optimization step is
completed with 205 scf iterations
BlockSize 16: total run 16h22 - - first optimization step is completed with
222 scf iterations
BlockSize 24: total run 13h15 - first optimization step is completed with
74 scf iterations
BlockSize 32: total run 19h09 - first optimization step is completed with
399 scf iterations
It should be noted that the energies at the end of the scf processes are
all similar and the optimisation terminates in 34 steps for all jobs.
I understood from the tutorial session in Santander last June that the
compilation of SIESTA in parallel can be a very tricky business. So I was
wandering if that scf behviour could in anyway be related to the
compilation? Or is it just a normal behaviour of SIESTA?
Cheers
Ludovic
