[CP2K:5395] Re: graphite in CP2K

[Matthias Krack]

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" <Matt... at gmail.com <javascript:>> 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" <matth... 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 
>>>> cp2k+... at googlegroups.com.
>>>> To post to this group, send email to cp... 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 
>> cp2k+... at googlegroups.com <javascript:>.
>> To post to this group, send email to cp... at googlegroups.com <javascript:>
>> .
>> 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/20140529/5108b705/attachment.htm>