<div dir="ltr">Hi Herbert,<div><br></div><div>excitingly there is actually a tutorial available now, that I think addresses you problem</div><div><br></div><div>http://www.cp2k.org/howto:converging_cutoff</div><div><br></div><div>Please give feedback! </div><div><br></div><div>I will say that the settings in the current version are probably "military grid" standard. If energies are converged to something sensible like microhartrees, I think your issues will be solved.</div><div><br></div><div>Matt</div><div><br>On Wednesday, February 19, 2014 3:20:28 PM UTC, hfruchtl wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir="ltr">Folks,<br><br>I am trying to do my first baby steps with CP2K, after several aborted attempts, so please tell me if I do something very stupid.<br><br>One thing that worries me after first tests is that geometry optimisations look converged, when they clearly aren't. In the example below, I start something that should be a water dimer at a very wrong geometry. When I plot the energy changes, they become smaller as expected, and after less than 30 steps the program finishes. But the geometry in the xyz file looks nothing like I expect (H2O)2 to look. When I optimise this structure with the program that must not be named, using the same functional, I get a proper dimer. If I then plug this into CP2K, it remains close to this geometry (good!) with a much lower energy than the first attempt (also good). I understand that BFGS may not be good from a bad guess, but I would expect CG to get there in the end, or at least not look like it converged. I'd be very surprised if this was a local minimum. In short: how do I know if I can trust an optimised geometry?<br><br>Input below. Thanks in advance,<br><br>  Herbert<br><br>&GLOBAL<br>  PROJECT water-dimer<br>  RUN_TYPE GEO_OPT<br>  PRINT_LEVEL high<br>&END GLOBAL<br><br>&MOTION<br>  &GEO_OPT<br>    MAX_ITER 2000<br>    MINIMIZER CG<br>  &END GEO_OPT<br>  &PRINT<br>    &TRAJECTORY<br>      LOG_PRINT_KEY T<br>      FORMAT xyz<br>      UNIT angstrom<br>      &EACH<br>        GEO_OPT 1<br>      &END EACH<br>      ADD_LAST NUMERIC<br>    &END TRAJECTORY<br>  &END PRINT<br>&END MOTION<br><br>&FORCE_EVAL<br>  METHOD Quickstep<br>  &DFT<br>    BASIS_SET_FILE_NAME /usr/local/CP2K/BASIS_MOLOPT<br>    POTENTIAL_FILE_NAME /usr/local/CP2K/GTH_POTENTIALS<br>    &MGRID<br>      CUTOFF 100<br>    &END MGRID<br>    &QS<br>    &END QS<br>    &SCF<br>      SCF_GUESS ATOMIC<br>    &END SCF<br>    &XC<br>      &XC_FUNCTIONAL PBE<br>      &END XC_FUNCTIONAL<br>    &END XC<br>  &END DFT<br><br>  &SUBSYS<br>    &CELL<br>      A    15.0 0.0 0.00<br>      B    0.0 15.0 0.0<br>      C    0.0 0.0 15.0<br>      PERIODIC NONE<br>    &END CELL<br>    &COORD<br>      O         0.0006535865        0.0348037292        6.5225572751<br>      H        -0.0003839912       -0.0241840602        7.5017980482<br>      H        -0.0019131905        1.0517623171        6.4318839506<br>      O         0.0244126401        0.0102938023        4.0045222106<br>      H        -0.0164725514       -0.0290451673        5.4795600635<br>      H         1.0326311856        0.2923983937        4.3857121035<br>    &END COORD<br><br>    &KIND O<br>      BASIS_SET DZVP-MOLOPT-GTH-q6<br>      POTENTIAL GTH-PBE-q6<br>    &END KIND<br>    &KIND H<br>      BASIS_SET DZVP-MOLOPT-GTH-q1<br>      POTENTIAL GTH-PBE-q1<br>    &END KIND<br>  &END SUBSYS<br>&END FORCE_EVAL<br><br><br><br></div></blockquote></div></div>