[CP2K-user] [CP2K:5398] Re: graphite in CP2K
fa...@gmail.com
fabia... at gmail.com
Sat Dec 5 09:55:20 UTC 2020
Dear Dmitrii,
The correct cell dimensions depend on the slab you built. I have never used
avogardo, but I assume it gives you this information somehow.
*"It seems that energy does not decrease much."*
The energy decreases by about 50 Hartree, or 3.5 eV per atom, in 6
iterations. This indicates that the initial structure was not even remotely
close to reasonable.
In the orthorhombic case the change is smaller, but 14 hartree is still far
too large.
I suggest you start with a smaller number of atoms to get a feeling for the
system without having to wait so long. First, optimize bulk graphene
(https://www.cp2k.org/howto:geometry_optimisation) and also try to relax
the cell dimensions. When you have done that, use the result to build the
slab.
Cheers,
Fabian
On Saturday, 5 December 2020 at 06:50:55 UTC+1 dre... at gmail.com wrote:
> Hi guys, could you suggest the right cell setting for graphite simulation.
> Should I use extra space in xy dimension to get right optimised geometry? I
> build slab from Avogadro with 384 atoms and xyz 17.04000000 14.75707288
> 13.20000000 A. I froze two bottom layer and allowed remaining top two layer
> to equilibrate.
>
> I am using following parameters:
> &GLOBAL
> PROJECT Graphite_geometry_optimization_moreMOs
> RUN_TYPE GEO_OPT
> PRINT_LEVEL MEDIUM
> &END GLOBAL
> &FORCE_EVAL
> METHOD QS
> &DFT
> BASIS_SET_FILE_NAME BASIS_MOLOPT
> POTENTIAL_FILE_NAME GTH_POTENTIALS
> CHARGE 0
> MULTIPLICITY 1
> &MGRID
> CUTOFF 800
> NGRIDS 5
> REL_CUTOFF 70
> &END MGRID
> &QS
> EPS_DEFAULT 1.0E-12
> WF_INTERPOLATION ASPC
> &END QS
> &SCF
> SCF_GUESS ATOMIC
> EPS_SCF 1.0E-7
> MAX_SCF 1000
> CHOLESKY INVERSE
> ADDED_MOS 100
> &SMEAR ON
> METHOD FERMI_DIRAC
> ELECTRONIC_TEMPERATURE [K] 300
> &END SMEAR
> &DIAGONALIZATION
> ALGORITHM STANDARD
> &END DIAGONALIZATION
> &MIXING
> METHOD BROYDEN_MIXING
> ALPHA 0.4
> NBROYDEN 8
> &END MIXING
> &END SCF
> &XC
> &XC_FUNCTIONAL
> &PBE
> &END PBE
> &END XC_FUNCTIONAL
> &vdW_POTENTIAL
> DISPERSION_FUNCTIONAL PAIR_POTENTIAL
> &PAIR_POTENTIAL
> PARAMETER_FILE_NAME dftd3.dat
> TYPE DFTD3
> REFERENCE_FUNCTIONAL PBE
> R_CUTOFF 15.0
> &END PAIR_POTENTIAL
> &END vdW_POTENTIAL
> &END XC
> &POISSON
> PERIODIC xy
> POISSON_SOLVER ANALYTIC
> &END POISSON
> &END DFT
> &SUBSYS
> &CELL
> ABC 18.46 13.53 50.0
> ALPHA_BETA_GAMMA 90.0 90.0 120.0
> PERIODIC xy
> &END CELL
> &COORD
> C 0.00000000 0.00000000 0.00000000
> ...
> C 17.75000000 13.52731681 9.90000000
> &END COORD
> &KIND C
> BASIS_SET DZVP-MOLOPT-GTH
> POTENTIAL GTH-PBE-q4
> &END KIND
> &END SUBSYS
> &END FORCE_EVAL
> &MOTION
> &CONSTRAINT
> &FIXED_ATOMS
> COMPONENTS_TO_FIX XYZ
> LIST 1..194
> &END FIXED_ATOMS
> &END CONSTRAINT
> &GEO_OPT
> OPTIMIZER LBFGS
> MAX_ITER 300
> &END GEO_OPT
> &END MOTION
>
> I spend 34 hours with 36 CPU and 120 GB of memory and still didn't
> optimised it yet. It seems that energy does not decrease much.
> 384
> i = 1, E = -2025.9045014398 <(904)%20501-4398>
> 384
> i = 6, E = -2075.1262328870
> If I change cell parameters to
> &SUBSYS
> &CELL
> ABC 18.46 13.53 50.0
> PERIODIC xy
> SYMMETRY ORTHORHOMBIC
> &END CELL
> 384
> i = 1, E = -2132.8940479508
> 384
> i = 11, E = -2146.1458464543
>
> It does not help much.
>
> Regards,
> Dmitrii
>
> On Friday, December 4, 2020 at 2:52:34 PM UTC+11 DMITRII Drugov wrote:
>
>> Thank you for your reply! I am still running optimisation, I will share
>> update once its done.
>>
>> Regards,
>> Dmitrii
>>
>> On Thursday, December 3, 2020 at 1:10:48 PM UTC+11 Travis wrote:
>>
>>> Hi,
>>>
>>> Graphite unit cell is hexagonal (
>>> https://materialsproject.org/materials/mp-48/). You can orthogonalize
>>> any cell though. Do it by hand or use a program like atomsk (
>>> https://atomsk.univ-lille.fr/),
>>>
>>> atomsk foo.cif -orthogonal-cell bar.cif
>>>
>>> -T
>>>
>>> On Wednesday, December 2, 2020 at 6:38:50 PM UTC-5 dre... at gmail.com
>>> wrote:
>>>
>>>> Good day dear CP2K users, do you think its right to use 90 90 90
>>>> orthorhombic symmetry for Graphite cell?
>>>> Should it be hexagonal 90 90 120 alpha betta gamma?
>>>>
>>>> Regrads,
>>>> Dmitrii
>>>>
>>>> On Thursday, May 29, 2014 at 8:01:13 PM UTC+10 mic... at gmail.com
>>>> wrote:
>>>>
>>>>> Thanks for the clarification, Matthias.
>>>>>
>>>>> I must admit that as someone who started off with PWs it is quite
>>>>> surprising to see that changing basis set within the same "class of
>>>>> complexity" can mess up things to the point of not being able to converge
>>>>> the SCF. In the future I'll pay more attention to testing the basis set
>>>>> when using CP2K, and take due note that there is much more than the number
>>>>> of polarization functions to define the quality of the basis!
>>>>>
>>>>> Best wishes,
>>>>> Michele
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Thu, May 29, 2014 at 9:17 AM, Matthias Krack <mat... at psi.ch>
>>>>> wrote:
>>>>>
>>>>>> Dear Michele,
>>>>>>
>>>>>> I would not consider graphite as a specifically nasty system. As Matt
>>>>>> already wrote, the basis sets in GTH_BASIS_SETS resulted from atomic
>>>>>> calculations using the actual GTH pseudopotential. Such an atomic basis set
>>>>>> optimisation gives in the case of carbon only a set of exponents and
>>>>>> contraction coefficients for a 2s and 2p function. The SZV (single-valence)
>>>>>> basis sets in GTH_BASIS_SETS are the results of such optimisations. You may
>>>>>> try the C SZV basis set and you will see that is behaves at least
>>>>>> reasonably for your system (you may also add a prmitive d polarisation
>>>>>> function -> SZVP) However, experience has shown that such a minimal basis
>>>>>> set is by far not accurate enough in most cases as it does not provide
>>>>>> sufficient flexibility. Thus it is not suited for production runs. The
>>>>>> double-zeta (DZV) GTH basis sets are derived from the corresponding SZV
>>>>>> basis sets just by using the smallest exponent as a primitive function for
>>>>>> the second valence function. This exponent is often rather small which
>>>>>> results in a quite diffuse valence function without any nodal structure.
>>>>>> These DZV basis sets were tested in molecular calculations in which they
>>>>>> worked. You see, however, that the procedure is not based on any strict
>>>>>> optimisation method. This deficiency may become apparent for condensed
>>>>>> phase systems like your system. For such systems I would always recommend
>>>>>> the use of the MOLOPT SR basis sets as already suggested which provide
>>>>>> results closer to PW calculations. The generation procedure of the MOLOPT
>>>>>> basis sets performs an optimisation of the contraction coefficients of all
>>>>>> included valence functions. In this respect the MOLOPT SR basis sets can be
>>>>>> considered as a kind of "second generation" CP2K basis sets.
>>>>>> Nevertheless, I would like to note that there are many cases in which
>>>>>> the GTH_BASIS_SETS work fine and their use may become beneficial as they
>>>>>> are computionally less demanding. I know that these basis set issues are
>>>>>> quite annoying, especially for people coming from the PW community.
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>> Matthias
>>>>>>
>>>>>>
>>>>>> On Wednesday, May 28, 2014 9:57:05 PM UTC+2, Michele Ceriotti wrote:
>>>>>>
>>>>>>> Dear Matt (and Marcella who basically replied the same in private),
>>>>>>>
>>>>>>> Thanks a million, using the molopt basis set does fix things. I
>>>>>>> had tried both the dzvp from basis_sets and gth_basis_set, and I was
>>>>>>> getting similar nonsense.
>>>>>>>
>>>>>>> I am a bit scared seeing how much difference it makes changing the
>>>>>>> basis set. Any idea why graphite should be such a nasty beast? I had
>>>>>>> experimented with different basis sets for water and never saw such a
>>>>>>> dramatic effect.
>>>>>>>
>>>>>>> All the best,
>>>>>>> Michele
>>>>>>> On 28 May 2014 19:23, "Matt W" <Mat... at gmail.com> wrote:
>>>>>>>
>>>>>>>> Hi Michele,
>>>>>>>>
>>>>>>>> please try using the MOLOPT basis sets provided with CP2K
>>>>>>>> ($CP2K_root/tests/QS/BASIS_MOLOPT) that prehaps give a more
>>>>>>>> suitable starting point for describing a "molecular" system like graphite
>>>>>>>> than atomic optimization based ones.
>>>>>>>>
>>>>>>>> Using a DZVP-MOLOPT-SR-GTH basis - I get SCF convergence in ~10
>>>>>>>> cycles and geometry converges in ~10 steps (with BFGS).
>>>>>>>>
>>>>>>>> Matt
>>>>>>>>
>>>>>>>> On Wednesday, May 28, 2014 5:19:30 PM UTC+1, Michele Ceriotti wrote:
>>>>>>>>>
>>>>>>>>> Hi Matthias,
>>>>>>>>> Thanks for the quick answer. I have already played with the
>>>>>>>>> obvious parameters, point is it is impossible to converge the scf properly.
>>>>>>>>> Everything looks like what you get when the geometry is crazy, and
>>>>>>>>> indeed my student tried to enlarge the cell (by almost 10%!) and got
>>>>>>>>> converged scf and more reasonable forces.
>>>>>>>>> However this is inconsistent with the literature and the results
>>>>>>>>> from siesta.
>>>>>>>>> We have been trying to fiddle with the scf parameters for days,
>>>>>>>>> but get consistently 100au forces on a geometry that should be very close
>>>>>>>>> to optimum.
>>>>>>>>> Do you see something wrong with how we define the cell or the
>>>>>>>>> positions?
>>>>>>>>> Best
>>>>>>>>> Michele
>>>>>>>>> On 28 May 2014 17:47, "Matthias Krack" <mat... at psi.ch> wrote:
>>>>>>>>>
>>>>>>>>>> Hi Michele,
>>>>>>>>>>
>>>>>>>>>> I would suggest to set EPS_DEFAULT in @QS section at least to
>>>>>>>>>> 1.0E-12 or lower and for the ALPHA in &MIXING I would also use a smaller
>>>>>>>>>> value like 0.2. Maybe this will help to converge your system properly.
>>>>>>>>>>
>>>>>>>>>> Matthias
>>>>>>>>>>
>>>>>>>>>> On Wednesday, May 28, 2014 4:20:44 PM UTC+2, Michele Ceriotti
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Dear CP2K community,
>>>>>>>>>>>
>>>>>>>>>>> I have been trying for a few days to set up calculations of
>>>>>>>>>>> graphite as an exercise for a student but I am getting the weirdest
>>>>>>>>>>> results. I am sure in the it will end up being a silly mistake in the
>>>>>>>>>>> input, but I can't get to see it so perhaps someone can help.
>>>>>>>>>>>
>>>>>>>>>>> Despite using a fairly large FD smearing, the SCF cycle has a
>>>>>>>>>>> hard time converging, and when the maximum number of steps is reached
>>>>>>>>>>>
>>>>>>>>>>> 50 Broy./Diag. 0.50E+00 1.2 0.00014351
>>>>>>>>>>> -819.2909959720 -2.28E-09
>>>>>>>>>>> *** SCF run NOT converged ***
>>>>>>>>>>>
>>>>>>>>>>> and the calculation carries on with what it has got, diagnostics
>>>>>>>>>>> are really strange.
>>>>>>>>>>>
>>>>>>>>>>> For a start, eigenvalues show two weird very low-energy states
>>>>>>>>>>> MO EIGENVALUES AND MO OCCUPATION NUMBERS
>>>>>>>>>>> # MO index MO eigenvalue [a.u.] MO occupation
>>>>>>>>>>> 1 -21.523076 2.000000
>>>>>>>>>>> 2 -21.517160 2.000000
>>>>>>>>>>> 3 -1.383548 2.000000
>>>>>>>>>>> 4 -0.510418 2.000000
>>>>>>>>>>>
>>>>>>>>>>> forces on the atoms are insane
>>>>>>>>>>> ATOMIC FORCES in [a.u.]
>>>>>>>>>>> # Atom Kind Element X Y Z
>>>>>>>>>>> 1 1 C 4.68736611 4.63921800
>>>>>>>>>>> -222.86999309
>>>>>>>>>>> 2 1 C -1.57720920 -4.48651652
>>>>>>>>>>> 124.33822840
>>>>>>>>>>> 3 1 C -5.01734639 3.10518104
>>>>>>>>>>> 176.16292919
>>>>>>>>>>>
>>>>>>>>>>> and so is the stress tensor
>>>>>>>>>>> STRESS TENSOR [GPa]
>>>>>>>>>>> X Y Z
>>>>>>>>>>> X -8233.84728056 8.05482610 0.90481573
>>>>>>>>>>> Y 8.05482610 -9552.76932222 -0.49445437
>>>>>>>>>>> Z 0.90481573 -0.49445437 -2526.59040628
>>>>>>>>>>>
>>>>>>>>>>> I was thinking of an error in the structure or the cell
>>>>>>>>>>> parameters, but I checked it many times and everything seems in order. The
>>>>>>>>>>> same structure, with same functional and similar parameters in SIESTA
>>>>>>>>>>> converges like a stone, and gives no problem whatsoever.
>>>>>>>>>>>
>>>>>>>>>>> Can you spot something obvious that I am missing? I'd really
>>>>>>>>>>> like to use CP2K for this exercise, but I can't seem to figure out what is
>>>>>>>>>>> going wrong.
>>>>>>>>>>>
>>>>>>>>>>> Many thanks,
>>>>>>>>>>> Michele
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>> You received this message because you are subscribed to a topic
>>>>>>>>>> in the Google Groups "cp2k" group.
>>>>>>>>>> To unsubscribe from this topic, visit
>>>>>>>>>> https://groups.google.com/d/topic/cp2k/koy91UtxlQw/unsubscribe.
>>>>>>>>>> To unsubscribe from this group and all its topics, send an email
>>>>>>>>>> to cp... at googlegroups.com.
>>>>>>>>>> To post to this group, send email to c... at googlegroups.com.
>>>>>>>>>> Visit this group at http://groups.google.com/group/cp2k.
>>>>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>>>>
>>>>>>>>> --
>>>>>>>> You received this message because you are subscribed to a topic in
>>>>>>>> the Google Groups "cp2k" group.
>>>>>>>> To unsubscribe from this topic, visit https://groups.google.com/d/
>>>>>>>> topic/cp2k/koy91UtxlQw/unsubscribe.
>>>>>>>> To unsubscribe from this group and all its topics, send an email to
>>>>>>>> cp... at googlegroups.com.
>>>>>>>> To post to this group, send email to c... at googlegroups.com.
>>>>>>>> Visit this group at http://groups.google.com/group/cp2k.
>>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>>
>>>>>>> --
>>>>>> You received this message because you are subscribed to a topic in
>>>>>> the Google Groups "cp2k" group.
>>>>>> To unsubscribe from this topic, visit
>>>>>> https://groups.google.com/d/topic/cp2k/koy91UtxlQw/unsubscribe.
>>>>>> To unsubscribe from this group and all its topics, send an email to
>>>>>> cp... at googlegroups.com.
>>>>>> To post to this group, send email to c... at googlegroups.com.
>>>>>> Visit this group at http://groups.google.com/group/cp2k.
>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>
>>>>>
>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cp2k.org/archives/cp2k-user/attachments/20201205/40d403d9/attachment.htm>
More information about the CP2K-user
mailing list