<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Nicholas,<div class=""><br class=""></div><div class="">I’ve experience two problems in line searches. One is that some of them require too many SCF calculations. For instance, Fletcher proposed a few quadratic line searches, and at each point you end up evaluating the function and its gradients (the function here is the SCF). In my test calculations, for each line search, I was calling 5 SCF. This resulted in extremely (perhaps painfully) slow geometry optimization. </div><div class=""><br class=""></div><div class="">The other problem is related to the confidence radius. If the line search is not in optimal conditions, it will penalize the step scaling, sometimes too much. For instance, some line searches are based on the Wolfe conditions, and if you do not have all criteria checked, you basically allow for a step of norm 1e-4 (Angstrom) or even less. Consequently, you don’t get out of the point you are, and this behaviour is kept for long. In many mathematical applications this is however better than shooting off and killing your root finding or minimization. </div><div class=""><br class=""></div><div class="">My first guess from checking a few papers of others is that something like the second point is happening with CP2K's Brent line search. The Brent method uses a mixture of golden section and quadratic fit of the function, and I believe that if you play around with the criteria that decides whether to use one or another, you will be able to improve results. The cost of the modification might however be that you will sacrifice the convergence properties of well behaved systems.</div><div class="">An alternative, if you like a bit of programming and code digging, would be to implement other methods. I can also give you some advice, since I spent some time on that problem.</div><div class=""><br class=""></div><div class="">Best</div><div class="">Filipe<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 22. Jul 2022, at 01:12, Nicholas Winner <<a href="mailto:nwinner@berkeley.edu" class="">nwinner@berkeley.edu</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">Hi all, <div class=""><br class=""></div><div class="">I'm working with some people that are using VASP while I am using CP2K. While CP2K has really fast SCF procedure, it seems to be slower when it comes to geometry optimization for some reason.</div><div class=""><br class=""></div><div class="">I've dug into VASP's manual and they claim that their CG method uses "a modified version of Brent's algorithm." No further details are given. Normally with CP2K, I use 2PNT line search with my CG minimizations, and I think this is pretty standard for everyone else. I do know that CP2K supports FIT and GOLD line search options which use Brent's algorithm (actually I don't 100% know how FIT and Brent's Algorithm are related, but gold uses it at least). However, GOLD line search is very slow in CP2K, as we are warned in the manual.</div><div class=""><br class=""></div><div class="">So, my hunch, is that CP2K with some type of gold or fit line search would be able to match this "modified Brent's algorithm" and provide faster minimization than what I am currently getting. Are there some insights that people can provide for choosing settings for gold line search that can give decent results? To remind, the flags we have to play with are:</div><div class=""><br class="">BRACK_LIMIT {Real}<br class=""><em class="">Limit in 1D bracketing during line search in Conjugate Gradients Optimization.</em><br class="">Default value: 1.00000000E+002<br class=""><br class=""><br class="">BRENT_MAX_ITER {Integer}<br class=""><em class="">Maximum number of iterations in brent algorithm (used for the line search in Conjugated Gradients Optimization)</em><br class="">Default value: 100<br class=""><br class="">BRENT_TOL {Real}<br class=""><em class="">Tolerance requested during Brent line search in Conjugate Gradients Optimization.</em><br class="">Default value: 1.00000000E-002<br class=""><br class="">INITIAL_STEP {Real}<br class=""><em class="">Initial step size used, e.g. for bracketing or minimizers. Might need to be reduced for systems with close contacts</em><br class="">Default value: 2.00000000E-001<br class=""><br class=""></div><div class=""><br class=""></div><div class="">Could it be that VASP uses a loose value for BRENT_TOL, or maybe a small number of max steps? Furthermore, what is the tolerance in the algorithm? Tolerance for the atomic position refinement, or forces?</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">If anyone has any ideas, it would be much appreciated.</div><div class=""><br class=""></div><div class="">-Nick</div><div class=""><br class="webkit-block-placeholder"></div>
-- <br class="">
You received this message because you are subscribed to the Google Groups "cp2k" group.<br class="">
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:cp2k+unsubscribe@googlegroups.com" class="">cp2k+unsubscribe@googlegroups.com</a>.<br class="">
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/cp2k/c3f8726c-7587-4240-8e97-c2a97f3ebdafn%40googlegroups.com?utm_medium=email&utm_source=footer" class="">https://groups.google.com/d/msgid/cp2k/c3f8726c-7587-4240-8e97-c2a97f3ebdafn%40googlegroups.com</a>.<br class="">
</div></blockquote></div><br class=""></div></body></html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups "cp2k" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:cp2k+unsubscribe@googlegroups.com">cp2k+unsubscribe@googlegroups.com</a>.<br />
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/cp2k/7057A62E-058A-4BDE-B946-D8E293951428%40gmail.com?utm_medium=email&utm_source=footer">https://groups.google.com/d/msgid/cp2k/7057A62E-058A-4BDE-B946-D8E293951428%40gmail.com</a>.<br />