NGL raises an exception when adding e.g. a cartoon or ribbon representation for some structures (other representations like ball+stick work). Other structures that only differ in the xyz coordinates of the atoms work without any issues (structures are predictions generated using CNS).
Example files are here: structure_examples.zip
Problem occurs using 2.0.0-dev.37 in my own app, and also on http://nglviewer.org/ngl/
Here is the error message displayed when loading crashes.pdb into http://nglviewer.org/ngl/
ngl.js:1 Uncaught (in promise) TypeError: Cannot read property 'traceAtomIndex' of undefined
at tx.ex.traceAtomIndex.get (ngl.js:1)
at ix.getAtomIndexByType (ngl.js:1)
at i (ngl.js:1)
at Object.next (ngl.js:1)
at Xw.vectorSubdivide (ngl.js:1)
at Xw.getPosition (ngl.js:1)
at qw.getPosition (ngl.js:1)
at qw.getSubdividedPosition (ngl.js:1)
at ngl.js:1
at nx.eachPolymer (ngl.js:1)
And here is the full stack trace from my own app: stack_trace.pdf
Is there any way to fix this, or alternatively, to work around this e.g. by patching the structure object before adding the representation?
Thanks for your help and such a great piece of software!
Thanks for the bug report, and yeah, It's a really subtle bug...
Your files both use the OT1 and OT2 atom names to represent the last two atoms of the file (the carboxylate oxygens on GLY263).
Because NGL doesn't recognise those as being standard names (it's expecting one of ['O', 'OC1', 'O1', 'OX1', 'OXT']) - it assigns the final residue's backbone type as coarse-grained.
This leads to an internal inconsistency: NGL correctly deduces the polymer isn't cyclic, but if the first and final residues are close-ish (within the coarse-grained threshold) then it thinks the first residue has a preceeding residue - however, because it's not cyclic, it tries eventually to address a residue with index -1 and it all blows up.
If you google "OT1 OT2 OXT" it seems this is a common pain point so I think the right thing to do is just to add OT1 to the list of atom names we accept as backbone O. (in structure-constants.js).
If you want to view the file right now then you can edit OT1 -> O and OT2 -> OXT
I'll check this doesn't break anything else and make a PR...
Thank you for debugging this @fredludlow
Thank you @fredludlow! Looking forward to the updated version, and I will patch the atom names in the meantime.
Fixed in my branch and PR (see link above):
You can test here (and download the built ngl.dev.js files from here too if you like)
https://fredludlow.com/ngl/fix-742/examples/webapp.html
@arose - would you be able to make a new dev release? Or tell me how I could do that?
@arose - would you be able to make a new dev release? Or tell me how I could do that?
will do
Hi @arose @fredludlow - do you already have a rough estimate when this fix might become available as a new dev release? Thanks!
Most helpful comment
Thanks for the bug report, and yeah, It's a really subtle bug...
Your files both use the OT1 and OT2 atom names to represent the last two atoms of the file (the carboxylate oxygens on GLY263).
Because NGL doesn't recognise those as being standard names (it's expecting one of
['O', 'OC1', 'O1', 'OX1', 'OXT']) - it assigns the final residue's backbone type as coarse-grained.This leads to an internal inconsistency: NGL correctly deduces the polymer isn't cyclic, but if the first and final residues are close-ish (within the coarse-grained threshold) then it thinks the first residue has a preceeding residue - however, because it's not cyclic, it tries eventually to address a residue with index -1 and it all blows up.
If you google "OT1 OT2 OXT" it seems this is a common pain point so I think the right thing to do is just to add OT1 to the list of atom names we accept as backbone O. (in structure-constants.js).
If you want to view the file right now then you can edit OT1 -> O and OT2 -> OXT
I'll check this doesn't break anything else and make a PR...