search

nglviewer / ngl

WebGL protein viewer
http://nglviewer.org/ngl/
MIT License
666 stars 169 forks source link

Hyperballs bond cutoff? #871

Closed gbayarri closed 3 years ago

gbayarri commented 3 years ago

Hi, we're playing a QM/MM trajectory where we have a break and generation of a covalent bond. A phosphorus atom splits from its unity and joins another.

It seems that the best molecular representation for dynamics bonds is Hyperballs, so we are using it.

In VMD, we see how the bond is changing from an unity to the other depending on the distance between atoms, while in NGL it's always looking for the first bond, no matter if the second distance is lower than the first one.

VMD screenshot (notice that the bond is at right):

Screenshot from 2021-06-10 10-16-37

NGL screenshot at about the same frame (notice that NGL is trying to establish a bond at left, despite the right distance is lower):

Screenshot from 2021-06-10 10-16-58

My question is if there is some parameter in hyperballs molecular representation to try to fix that or maybe to do some trick in the PDB file. We have added the CONECT at the pdb file and modified the pdb for adding both atoms to the same residue, but it's still not working.

arose commented 3 years ago

HI @gbayarri, I am afraid recalculating bonds is not supported in NGL. It is a good idea to add all possible bonds to the topology. However as far as I remember there is some maximum bond length.

gbayarri commented 3 years ago

Hi @arose, we have solved it modifying the topology as you suggested. Actually we already tried, but we had a problem: modify manually the CONECT didn't work.

Taking a look to the NGL PDB parser:

https://github.com/nglviewer/ngl/blob/master/src/parser/pdb-parser.ts#L361

It parses 6 characters after CONECT. In our case, these bonds were:

CONECT 16679 16674 CONECT 16679 16414

So modifying the code above to:

CONECT1667916674 CONECT1667916414

It works!

test

But maybe it would be a good idea to put this value to 7 in order to allow connections between atoms from 10.000 upwards.

I leave this issue opened in case someone will tag it as an enhancement.

arose commented 3 years ago

This looks really nice, thanks for sharing!

The parser is that way on purpose as the PDB format is a fixed column format here and does not recognizes white space as separators. http://www.wwpdb.org/documentation/file-format-content/format33/sect10.html#CONECT

gbayarri commented 3 years ago

Ok, so in this case it was our fault for not reading this part of the PDB documentation ;)

Thanks!