[Pw_forum] nscf restart
sclauzer at sissa.it
Wed Jun 8 09:18:49 CEST 2011
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.
> Could you give an advise if there is anything wrong on way I described above?
> Thank you very much,
> University of Houston
> Pw_forum mailing list
> Pw_forum at pwscf.org
§ Gabriele Sclauzero, EPFL SB ITP CSEA
PH H2 462, Station 3, CH-1015 Lausanne
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users