[CP2K:2126] Re: assignment of covalent radii for MM atoms
Teodoro Laino
teodor... at gmail.com
Wed Jun 10 15:48:29 UTC 2009
These are two different problems:
1) since you use amber topologies you should never handle mm types,
the only case would be for specifying RADIUS in QM/MM. In this case
you can dump a PDB file where the new kinds are written and start from
there..
In the future I may think about assigning RADIUS to elements instead
of kinds but for the time being, unfortunately, there is (for amber
only) a little overhead.
2) the error you see is related to QS. you didn't specify the KIND
section in the subsys for the QM atoms. These kinds have nothing to do
with amber but it was you to specify them with the QM_KINDS in the
QMMM section.
---------------------------------------------
Teodoro Laino
Zurich Switzerland
Contact info:
Tel.: http://www.jajah.com/Teo
E-mail: teo... at laino.eu
teodor... at gmail.com
---------------------------------------------
On 10 Jun 2009, at 17:25, Marius Retegan <marius.s... at gmail.com>
wrote:
> So if I want to use amber topologies can you think of an "easy"
> method for preparing the input files for QM/MM calculations?
> Also even if I don't assign any kinds to mm atoms I get this error
> message:
>
> *
> *** ERROR in read_atomic_kind (MODULE atomic_kind_types) ***
> *
>
>
> *** No &KIND section was possible to associate to the atomic kind
> <O>. ***
> *** The KIND section were also scanned for the corresponding
> element <O> ***
> *** and for the DEFAULT section but no match was found. Check your
> input ***
> ***
> file!
> ***
>
>
> *** Program stopped at line number 1538 of MODULE
> atomic_kind_types ***
>
> ===== Routine Calling Stack =====
>
> 5 read_atomic_kind
> 4 read_atomic_kind_set
> 3 quickstep_create_force_env
> 2 qmmm_create_force_env
> 1 CP2K
> CP2K| Abnormal program termination, stopped by process number 0
>
> Thanks
> Marius
>
> On Wed, Jun 10, 2009 at 4:24 PM, Teodoro Laino <teodor... at gmail.com
> > wrote:
> Because for CP2K a kind has a specific charge. Same kinds have same
> charge. For amber the charge has nothing to do with the kinds, i.e.
> same kinds can have different charges.
>
>
> ---------------------------------------------
> Teodoro Laino
> Zurich Switzerland
>
> Contact info:
> Tel.: http://www.jajah.com/Teo
> E-mail: teo... at laino.eu
> teodor... at gmail.com
> ---------------------------------------------
>
> On 10 Jun 2009, at 16:12, Marius Retegan
> <marius.s... at gmail.com> wrote:
>
>> But why can't the atomic kinds be assigned from the amber parameter
>> file instead of being automatically generated?
>>
>> On Wed, Jun 10, 2009 at 4:09 PM, Teodoro Laino <teodor... at gmail.com
>> > wrote:
>> No, for varius reasons of compatibility between AMBER and CHARMM
>> (which is the FF natively supported) this is not possible.
>>
>> ---------------------------------------------
>> Teodoro Laino
>> Zurich Switzerland
>>
>> Contact info:
>> Tel.: http://www.jajah.com/Teo
>> E-mail: teo... at laino.eu
>> teodor... at gmail.com
>> ---------------------------------------------
>>
>> On 10 Jun 2009, at 16:06, Marius Retegan
>> <marius.s... at gmail.com> wrote:
>>
>>> Hi,
>>>
>>> When using amber parameter files the atomic kind name
>>> is automatically generated and is different from the atomic
>>> kinds in the amber force field. Is it possible to change this
>>> behaviour?
>>>
>>> Thanks
>>> Marius
>>>
>>> On Tue, Jun 9, 2009 at 6:12 PM, Teodoro Laino <teodor... at gmail.com
>>> > wrote:
>>>
>>> Regtests are there not to provide meaningful example but for
>>> checking
>>> integrity while developing.
>>> In this case that regtest is testing something totally different
>>> than
>>> the covalent radius for QMMM.
>>> As you realized by yourself, if you provide the correct types, the
>>> right
>>> radius will be parsed and used.
>>>
>>> Teo
>>>
>>>
>>> Marius Retegan wrote:
>>> >
>>> >
>>> > On Tue, Jun 9, 2009 at 5:35 PM, Teodoro Laino <teodor... at gmail.com
>>> > <mailto:teodor... at gmail.com>> wrote:
>>> >
>>> >
>>> > By default all atoms have the same covalent radius.
>>> >
>>> >
>>> > I got this.
>>> >
>>> >
>>> > Please use the tools provided by Axel and the CMM folks
>>> > (covalent_radii.pl, you can get here in this group under
>>> Files) if you
>>> > want realistic values.
>>> >
>>> >
>>> > What confused me is that the input that I was referring to has the
>>> > following section:
>>> > &MM_KIND H
>>> > RADIUS 0.440
>>> > &END MM_KIND
>>> > &MM_KIND O
>>> > RADIUS 0.780
>>> > &END MM_KIND
>>> > With this all atoms get the same radii. So this part of the
>>> input it's
>>> > useless.
>>> > If I change it to HT and OT I get the expected values.
>>> > Marius
>>> >
>>> >
>>> >
>>> > Regards
>>> > Teo
>>> >
>>> > Marius Retegan wrote:
>>> > > Apparently cp2k assigns the same covalent radius for the
>>> MM atoms.
>>> > > I took the input file from tests/QMMM/QS/regtest-4/
>>> wat_nacl.inp and
>>> > > changed the print level to medium.
>>> > > This is what I get:
>>> > >
>>> > > MM POINT CHARGES GENERATING THE QM/MM ELECTROSTATIC
>>> > POTENTIAL
>>> > >
>>> > >
>>> >
>>> ---
>>> ---
>>> -------------------------------------------------------------------
>>> > > MM ATOM: 3 RADIUS: 1.511781 CHARGE: 0.417000
>>> CORR.
>>> > > RADIUS 1.511781
>>> > > MM ATOM: 4 RADIUS: 1.511781 CHARGE: -0.834000
>>> CORR.
>>> > > RADIUS 1.511781
>>> > > MM ATOM: 5 RADIUS: 1.511781 CHARGE: 0.417000
>>> CORR.
>>> > > RADIUS 1.511781
>>> > > MM ATOM: 6 RADIUS: 1.511781 CHARGE: 0.417000
>>> CORR.
>>> > > RADIUS 1.511781
>>> > > MM ATOM: 7 RADIUS: 1.511781 CHARGE: -0.834000
>>> CORR.
>>> > > RADIUS 1.511781
>>> > > MM ATOM: 8 RADIUS: 1.511781 CHARGE: 0.417000
>>> CORR.
>>> > > RADIUS 1.511781
>>> > > MM ATOM: 9 RADIUS: 1.511781 CHARGE: 0.417000
>>> CORR.
>>> > > RADIUS 1.511781
>>> > > MM ATOM: 10 RADIUS: 1.511781 CHARGE: 1.000000
>>> CORR.
>>> > > RADIUS 1.511781
>>> > > MM ATOM: 11 RADIUS: 1.511781 CHARGE: -1.000000
>>> CORR.
>>> > > RADIUS 1.511781
>>> > >
>>> > > Atom 3 is an oxygen, while 4 if a hydrogen. Is this
>>> related to
>>> > > periodic QM/MM?
>>> > > Thanks
>>> > > Marius
>>> > >
>>> > > >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > >
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>
>
>
>
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cp2k.org/archives/cp2k-user/attachments/20090610/ea1ef2b0/attachment.htm>
More information about the CP2K-user
mailing list