Ngl: Adding cartoon representation raises TypeError

Created on 2 May 2020  路  6Comments  路  Source: nglviewer/ngl

Problem description

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

  • works.pdb displays without any issues
  • crashes.pdb raises an exception as one adds the representation

Version information

Problem occurs using 2.0.0-dev.37 in my own app, and also on http://nglviewer.org/ngl/

Stack trace

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!

bug

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...

All 6 comments

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!

Was this page helpful?
0 / 5 - 0 ratings