[CP2K-user] [CP2K:5398] Re: graphite in CP2K
Travis
polla... at gmail.com
Thu Dec 3 02:10:48 UTC 2020
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/to
>>>>>>> pic/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/20201202/e8b4d9b7/attachment.htm>
More information about the CP2K-user
mailing list