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