[Pw_forum] nscf restart

[Vi Vo]

Dear Gabriele,

Thanks for your help.  I will follow your advise to increase the number of 
CPUs.  However, I have another question.  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.  Is it possible that I double the 
number of CPUs and use -npool 2?    



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 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quantum-espresso.org/pipermail/users/attachments/20110608/21832c40/attachment.html>