Geometry optimisation converges to nonsense

Matt W MattWa... at gmail.com
Wed Feb 19 16:08:35 UTC 2014


Hi Herbert,

excitingly there is actually a tutorial available now, that I think 
addresses you problem

http://www.cp2k.org/howto:converging_cutoff

Please give feedback! 

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.

Matt

On Wednesday, February 19, 2014 3:20:28 PM UTC, hfruchtl wrote:
>
> Folks,
>
> 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.
>
> 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?
>
> Input below. Thanks in advance,
>
>   Herbert
>
> &GLOBAL
>   PROJECT water-dimer
>   RUN_TYPE GEO_OPT
>   PRINT_LEVEL high
> &END GLOBAL
>
> &MOTION
>   &GEO_OPT
>     MAX_ITER 2000
>     MINIMIZER CG
>   &END GEO_OPT
>   &PRINT
>     &TRAJECTORY
>       LOG_PRINT_KEY T
>       FORMAT xyz
>       UNIT angstrom
>       &EACH
>         GEO_OPT 1
>       &END EACH
>       ADD_LAST NUMERIC
>     &END TRAJECTORY
>   &END PRINT
> &END MOTION
>
> &FORCE_EVAL
>   METHOD Quickstep
>   &DFT
>     BASIS_SET_FILE_NAME /usr/local/CP2K/BASIS_MOLOPT
>     POTENTIAL_FILE_NAME /usr/local/CP2K/GTH_POTENTIALS
>     &MGRID
>       CUTOFF 100
>     &END MGRID
>     &QS
>     &END QS
>     &SCF
>       SCF_GUESS ATOMIC
>     &END SCF
>     &XC
>       &XC_FUNCTIONAL PBE
>       &END XC_FUNCTIONAL
>     &END XC
>   &END DFT
>
>   &SUBSYS
>     &CELL
>       A    15.0 0.0 0.00
>       B    0.0 15.0 0.0
>       C    0.0 0.0 15.0
>       PERIODIC NONE
>     &END CELL
>     &COORD
>       O         0.0006535865        0.0348037292        6.5225572751
>       H        -0.0003839912       -0.0241840602        7.5017980482
>       H        -0.0019131905        1.0517623171        6.4318839506
>       O         0.0244126401        0.0102938023        4.0045222106
>       H        -0.0164725514       -0.0290451673        5.4795600635
>       H         1.0326311856        0.2923983937        4.3857121035
>     &END COORD
>
>     &KIND O
>       BASIS_SET DZVP-MOLOPT-GTH-q6
>       POTENTIAL GTH-PBE-q6
>     &END KIND
>     &KIND H
>       BASIS_SET DZVP-MOLOPT-GTH-q1
>       POTENTIAL GTH-PBE-q1
>     &END KIND
>   &END SUBSYS
> &END FORCE_EVAL
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cp2k.org/archives/cp2k-user/attachments/20140219/7c86fa9b/attachment.htm>


More information about the CP2K-user mailing list