Page 1 of 1

restarting optimization after timeout

Posted: Fri Mar 11, 2016 2:52 pm
by Katharina Doblhoff
Is there any reasonable possibility to restart a vmc optimization after a timeout called by max_runtime?
The outfile does tell you that the next iteration will not fit into the allotted timeslot, but restarting is not possible using the --continue flag.

Is there any reasonable method to do so? Simply putting the last correlation.out to correlation.data and restarting the calculation with a reduced number of cycles is most likely not a good idea, since one would then use the same random seed as in the first part of the calculation. Reading in config.in would be possible by using opt_vmc, but the config.in file may be flagged as having been produced by opt and not by vmc, depending on when the calculation stopped.

Is there any good solution to that other than "Give your calculation enough runtime?" It would be great if the optimization could simply resume where it has stopped. In principle, I guess all relevant information has to be there: a config file and the last correlation.out, it was working with.

Thanks,
Katharina

Re: restarting optimization after timeout

Posted: Fri Mar 11, 2016 5:53 pm
by Neil Drummond
Dear Katharina,

Simply putting the last correlation.out to correlation.data and restarting the calculation with a reduced number of cycles should be fine (using the same random seed doesn't really matter here, although you could always avoid this by setting random_seed to timer).

Best wishes,

Neil.

Re: restarting optimization after timeout

Posted: Mon Mar 14, 2016 8:30 am
by Katharina Doblhoff
Dear Neil,
Thank you for your answer. Just to make this a bit clearer for anybody who ever has the same question> One just has to make sure one restarts with opt_vmc or with vmc_opt depending on where it stopped. Concerning the random numbers: These are read in as long as there is a config.in file. (at least I got different results when restarting with and without the file. If it had started from the same random seed, I would have gotten identical results). Interestingly enough though, one should not set newrun=F. Instead one has to leave newrun=T in all cases. (otherwhise it looks for a config.in file in the next iteration, where it should generate new configs)
All the best,
Katharina