[Pw_forum] nscf restart

[Vi Vo]

Dear Garbriele,

Thank you very much for your help.

Vi




________________________________
From: Gabriele Sclauzero <sclauzer at sissa.it>
To: PWSCF Forum <pw_forum at pwscf.org>
Sent: Thu, June 9, 2011 2:29:21 AM
Subject: Re: [Pw_forum] nscf restart



Il giorno 08/giu/2011, alle ore 20.20, Vi Vo ha scritto:

Is it possible that I double the number of CPUs and use -npool 2?    
>
Yes, it is possible, and that's what you should to in order to speed up the 
calculation.

 I see the number of planes printed out in the beginning of the output is 
90CPUs.  Thus the max number of CPUs that I can use is 90CPUs, ie one CPU per 
plane. 

The number of cpus employed for the FFT parallelization is 
nproc_pool=nproc_tot/npool. Therefore, if you double the number of processors 
(let's say from 90 to 180) and double the number of pools (from 1 to 2), then 
you will still have the same parallelization scheme for the FFT grid (within 
each pool).

In principle nothing forbids you to use more cpus than the number of FFT planes, 
but this might be inefficient. Then you should employ task groups or threading 
via OpenMP (for more detail, please refer to the user guide or to the QE paper, 
linked in the bibliography section of the quantum-espresso.org website)


HTH

GS


>
>Thanks,
>
>Vi
>
>
________________________________
From: Gabriele Sclauzero <sclauzer at sissa.it>
>To: PWSCF Forum <pw_forum at pwscf.org>
>Sent: Wed, June 8, 2011 12:18:49 AM
>Subject: Re: [Pw_forum] nscf restart
>
>Dear Vi,
>
>
>Il giorno 07/giu/2011, alle ore 23.46, Vi Vo ha scritto:
>
>Dear All,
>>
>>I need to run nscf with a kpt-grid 17x17x17.  However, I can only have 24 hrs to 
>>run, so the job won't be finished in that short time slot.  I will need to 
>>restart after every 24hrs.  If I use the 'restart' option, one thing I am 
>>worried is that after the first run, the scf charge density file will be 
>>overwritten and replaced by nscf charge density file. 

I don't think that the nscf run will overwrite the scf charge density file. I 
think it will just be read and used to compute the scf potential. What will be 
changed are the eigenfunctions in .wfc and the eigenvalues in the restart files 
inside .save

When the job is restarted, the charge density file saved in previous run and the 
*.wfc files will be read.  Is the continuing nscf calculation still correct?
>

I remember that this could be done it correctly if one specifies disk_io="high". 
Then some additional files should be written to keep track at which k-point and 
band the calculation is stopped. At that time the max_seconds option was not 
working in that case (because the check is outside the subroutine electrons), so 
the run is interrupted "brutally" (i.e. with kill by the queuing system, in your 
case). Anyway the restart should work fine anyway if you add this option. You 
can also add verbosity="high" to see how many k-points have been computed up to 
that point. 


>One other option is that I can look at how many kpts needed for the grid 
>17x17x17 by using the kpt list printed out in the output file if 17x17x17 is 
>used, then run smaller jobs, each of which, for example, includes the nscf 
>calculation of 20 kpts.  However, when I started the job in this way, more kpts 
>than those that I specified in the input file were calculated, eg 40kpts instead 
>of 20kpts.  I understand the code searched for other equivalent kpts and 
>calculate them.  Because of this, the job required longer time to finish all 40 
>kpts than the time I plan.  In order to avoid this, I specified the option 
>"nosym=.true.", so that only those kpts I specify in the input file are 
>calculated.  However, I am not sure if it is correct to do in this way. 

Not sure either that this gives you exactly what you want and I don't know if 
there are other side effects.


Another point encountered is that by chopping into smaller jobs, the kpt weight 
in each 20kpts-job is not correct anymore due to the way the code compute the 
kpt weight. 

Of course if you want to compute DOS or PDOS, and therefore need also correct 
weights, the above method is not the ideal.

What about using more processors together with pools? You should be able to 
reduce by about a half the running time by doubling the number of processors 
with -npool 2, for instance.

HTH
>
>
>
>
>GS
>
>
>
>
>Could you give an advise if there is anything wrong on way I described above?
>>
>>Thank you very much,
>>
>>Vi
>>University of Houston      
>>
>>_______________________________________________
>>Pw_forum mailing list
>>Pw_forum at pwscf.org
>>http://www.democritos.it/mailman/listinfo/pw_forum
>>
>
>
>§ Gabriele Sclauzero, EPFL SB ITP CSEA
>   PH H2 462, Station 3, CH-1015 Lausanne
>_______________________________________________
>Pw_forum mailing list
>Pw_forum at pwscf.org
>http://www.democritos.it/mailman/listinfo/pw_forum
>


§ Gabriele Sclauzero, EPFL SB ITP CSEA
   PH H2 462, Station 3, CH-1015 Lausanne 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quantum-espresso.org/pipermail/users/attachments/20110609/cb60e062/attachment.html>