[CP2K:5819] Removing DFTB interaction between particular atoms?

[Rafael Soler-Crespo]

Dear Ralph,

Thanks! Your suggestion seems to have done the trick, and everything is 
looking great. I did a quick simulation with a couple of these B-B bonds 
monotonically straining the box, and the system seems to be following 
fracture mechanics quite well. Nonetheless, I have a quick question 
regarding classifying the atom as a real element (in this case, boron) and 
some problems that may cause in actual implementations. 

If I run molecular mechanics and/or molecular dynamics informed with DFTB 
energies and, consequently, forces, will the mass, atomic radii and stored 
information for boron be used in the calculation instead of carbon's for B 
atoms? I bring this up because when I print with one B atom present in my 
input, using a HIGH level of output, the output contains the mass of a 
boron atom (and its relevant information) when printing the structure 
initially. However, in xx.spl, xc.spl and cx.spl we have forcefully defined 
the mass of the system as that of a C atom. I'm just worried doing 
molecular mechanics and/or molecular dynamics with this setup will end up 
giving wrong mechanics/dynamics, as the atomic information for the B atoms 
in the "cracked bond" are incorrect so as to circumvent CP2K and use our 
own parameter sets.

What do you think?

Thanks for both your time and patience,
Rafael

On Thursday, November 6, 2014 4:37:20 AM UTC-6, Ralph wrote:
>
> Dear Rafael,
>
> Thanks for trying my suggestion. I played around with it some more and got 
> something more reasonable after making the following changes:
>
>    - Instead of using atom symbol X, you have to use a 'real' element for 
>    your non-interacting carbons. I called it B.
>    - Drop the KIND X // ELEMENT C ... part in &SUBSYSTEMS. 
>    - In the xc.spl and cx.spl files, remove lines 2 and 3. (The format is 
>    different for homo- and heteronuclear interactions, compare e.g. oo.spl and 
>    oh.spl in a water setup).
>    - In the xx.spl, in the spline section, leave the first two columns as 
>    is, set the others to zero. The first line after Spline should be "0 0 -1" 
>    to turn off also the very short-range repulsion.
>
> I attached the xx.spl file and param_table files.
>
> Using these settings the following things work seemingly fine:
>
>    - A graphene sheet with only one "B" atom behaves like an unmodified 
>    graphene sheet
>    - A graphene sheet with two adjacent "B" still looks physical, but the 
>    B-B bond compresses, presumably because all repulsion has been turned off. 
>    C-C and C-"B" bonds remain mostly unperturbed.
>
> Let me know how this works out for you.
>
>
> Ralph
>
> On Thu, Nov 6, 2014 at 12:42 AM, Rafael Soler-Crespo <raso... at gmail.com 
> <javascript:>> wrote:
>
>> Hi Ralph,
>>
>> Thanks for your insightful (and quite creative!) reply. It looks like a 
>> great starting point for what I intend to do so I can replicate the paper. 
>> I followed your suggestion, and I generated xc.spl, cx.spl and xx.spl 
>> files. I also made the xx.spl file all zeros essentially. I also added them 
>> to the scc_parameter file (which I renamed parameter_table some time ago). 
>> I'm attaching the files here. Then, I adjusted my geometry to have two X 
>> atoms in the XYZ input (which is attached too) to represent my initial 
>> break or crack.
>>
>> When I tried to run my job, it wouldn't start as the KIND X was not 
>> defined in the input. I defined the KIND X using:
>>
>>   &KIND X
>>    ELEMENT C
>>   &END KIND
>>
>> But when CP2K runs it says:
>>
>>  *** 00:18:09 WARNING in atomic_kind_types:read_atomic_kind :: 
>> Information ***
>>  *** provided in the input file regarding POTENTIAL for KIND <X> will be 
>>   ***
>>  *** ignored!atomic_kind_types.F line 2341 
>>
>> And the results look extremely unphysical (3 carbon atoms collapsing 
>> essentially one into the other). I thought that removing xx.spl, xc.spl and 
>> cx.spl would perhaps make it work, but it didn't work either. When I make 
>> change X atoms to C atoms in the input structure, everything is back to 
>> normal. This makes me think the problem is related to how KIND is working 
>> when selecting parameters to use (treating them as if they weren't there?). 
>> When I print their charges and mass, it all looks right. Do you have any 
>> idea if I am defining my KIND incorrectly, or what could be my issue?
>>
>> I've also attached my input, to keep the mailing list clean.
>>
>> Thanks,
>> Rafael
>>
>> On Wednesday, November 5, 2014 11:25:14 AM UTC-6, Ralph wrote:
>>>
>>> Hi,
>>>
>>> I think it should be feasible to do this without changes to the code. In 
>>> your DFTB calculation, find the Slater-Koster parameter file for Carbon, 
>>> should be something like 'cc.spl', make three copies of that file '
>>> cx.spl', 'xc.spl', 'xx.spl'. Then edit the file that assigns parameters 
>>> to atoms ('scc_parameter' ?), it contains a list of what spl file to 
>>> use for which interaction. Add the following lines:
>>>   C   X  cx.spl
>>>   X   C  xc.spl
>>>   X   X  xx.spl
>>> (the C C interaction should already be there).
>>>
>>> You can then replace your two desired carbons in graphene by atoms of 
>>> type X, and tune their interaction by modifying the xx.spl file. In the 
>>> simplest case, set all columns to zero to turn off all interactions. You 
>>> can also scale the interaction, or turn off orbital-specific components.
>>> X atoms will still behave like C atoms to other C atoms.
>>>
>>> See my slides from the cp2k tutorial for details on setting up a dftb 
>>> calculation and on the format of the .spl files.
>>>     http://ralph.koitz.info/doc/dftb_cp2k.pdf
>>>
>>> Hope that helps,
>>> Ralph
>>>
>>> On Wed, Nov 5, 2014 at 4:35 PM, Rafael Soler-Crespo <raso... at gmail.com
>>> > wrote:
>>>
>>>> Hi all,
>>>>
>>>> I'm trying to perform a calculation to replicate a MD paper on CP2K 
>>>> using DFTB to see if the findings still hold (out of curiosity). In this 
>>>> paper, a crack is imposed on graphene by removing explicitly atoms from the 
>>>> material. I want to do this a little differently by turning off 
>>>> interactions between two neighboring carbon atoms. My system has around 
>>>> 7000 carbon atoms, and I want to forcefully zero any interactions between 
>>>> two adjacent C atoms. I searched around the documentation, but I couldn't 
>>>> find a great way to do this. Is it possible for someone to let me know if 
>>>> this is possible in CP2K, and if it is not, if it could be coded in 
>>>> principle?
>>>>
>>>> Thanks,
>>>> Rafael
>>>>
>>>> -- 
>>>> You received this message because you are subscribed to the Google 
>>>> Groups "cp2k" group.
>>>> To unsubscribe from this group and stop receiving emails from it, 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 the Google Groups 
>> "cp2k" group.
>> To unsubscribe from this group and stop receiving emails from it, 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/20141107/2f05c3ee/attachment.htm>