[gmx-developers] How to obtain the element of an atom?

[Joe Jordan]

Hi all,

I think that this is properly within the scope of gmx development if Lorién
believes there is some issue with the underlying code. I might suggest
though that this is still not the right place for such discussions. If a
minimal working example of the issue can be found, it should be posted on
gitlab as a bug report. I think the confusion on where to post such issues
is natural, since there are indeed a number of channels. This mailing list
is mostly for low frequency anouncements, or for people seeking hints on
how to get started on projects involving coding. As such, I think this was
a reasonable enough place to ask for a small amount of insight, but that
now the discussion should move to gitlab if there are further issues.

On Wed, Feb 17, 2021 at 8:35 AM Bert de Groot <bgroot at gwdg.de> wrote:

> Hi,
>
> This is not about gmx development, so gmx-developers is not the
> appropriate channel.
>
> Lysozyme has multiple disulfide bonds (connecting cysteines), you may be
> looking at one of those.
>
> Bert
>
> On 16/02/2021 17:18, Lorién López Villellas wrote:
>
> Hello again.
>
> As Dmitry suggested, we have been working with the *gmx_mtop_t* data. So
> far, it seems that it is what we needed.
>
> However, we are having some trouble with the *iatoms* structure (
> *idef->il[F_CONSTR].iatoms* in *Constraints::Impl::setConstraints()*). We
> are currently testing our algorithm with the GROMACS-Lysozime tutorial (the
> md-simulation part). The *elements_iatoms.txt* file attached contains
> *iatoms* and each atom element when calling to setConstraints(). We see
> some weird bonds:
>
>    - Bond 1938, which is part of a cysteine amino acid (let us call it
>    amino acid x), connects atom 1910 (carbon) with atom 1913 (sulfur), forming
>    a C-S bond, which is just right.
>    - Bond 100, connects atom 98 (sulfur) with atom 1913 (the sulfur atom
>    of amino acid x). As far as I know, a connection S-S is not even possible
>    in a peptide-chain.
>    - The bond that should connect atom 1913 with a hydrogen atom does not
>    exist.
>
> What is weird is that almost every bond makes sense, except some bonds
> like the ones shown below. As this structure is used in SHAKE, I guess we
> are doing something wrong.
>
> Thank you all in advance.
>
> Regards,
> Lorién
>
> El jue, 11 feb 2021 a las 19:16, Lorién López Villellas (<
> lorien.lopez at bsc.es>) escribió:
>
>> Hi.
>>
>> One the possible solutions (there are atomic numbers stored in the
>>> gmx_mtop_t)
>>
>>
>> I think we can work with that. Thanks!
>>
>> But that would make the algorithm work only for proteins. Why not do the
>>> numbering based on bond connectivity?
>>
>>
>> We have two versions of the algorithm, a sequential one that works with
>> any molecule and a parallel one that, as you say, only works with proteins.
>> The parallelization of the algorithm is based on the structure of the
>> peptide chain. The numbering we use is extremely specific; each amino acid
>> bond must always have the same index. The reordering algorithm needs to
>> identify each of the molecule bonds precisely. We have not found a way to
>> achieve that without using the additional information that the atoms'
>> element provides.
>>
>> Regards,
>> Lorién
>>
>> El jue, 11 feb 2021 a las 17:30, Berk Hess (<hess at kth.se>) escribió:
>>
>>> On 2/11/21 4:22 PM, Lorién López Villellas wrote:
>>>
>>> Hi.
>>>
>>> Why is the element number relevant for constraints? The element number
>>>> is never used in MD calculations.
>>>
>>>
>>> We have performed a heavy code optimization based on the structural
>>> patterns of the peptide chains. In order to apply this optimization, we
>>> need a very specific bond numbering. To get to this bond numbering, we use
>>> a bond reordering phase. The reordering algorithm needs to know the
>>> elements of the molecule's atoms to locate itself.
>>>
>>> But that would make the algorithm work only for proteins. Why not do the
>>> numbering based on bond connectivity?
>>>
>>> Cheers,
>>>
>>> Berk
>>>
>>> --
>>> Gromacs Developers mailing list
>>>
>>> * Please search the archive at
>>> http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List before
>>> posting!
>>>
>>> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>>>
>>> * For (un)subscribe requests visit
>>> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers
>>> or send a mail to gmx-developers-request at gromacs.org.
>>
>>
>
>
> --
> Gromacs Developers mailing list
>
> * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List before
> posting!
>
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>
> * For (un)subscribe requests visit
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers
> or send a mail to gmx-developers-request at gromacs.org.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20210217/f4ad29e1/attachment.html>