An additional complication with his is that we don’t actually know the sequence of the intron chain, as this is a steady state endogenous sample with lots of different sequences bound. Plus, it is a circular (or more accurate lariat shaped ) molecule with an
internal covalent bond, so it’s a bit of a headache.
I will try and get in touch with the PDB to try and resolve this.
From: Artie Kushner <rtkushner@gmail.com>
Date: Wednesday, 26. August 2026 at 11:34
To: Vorländer,Matthias Kopano <matthias.vorlaender@imp.ac.at>
Cc: Greg Couch <gregc@cgl.ucsf.edu>; chimerax-users@cgl.ucsf.edu <chimerax-users@cgl.ucsf.edu>
Subject: Re: [chimerax-users] Re: Overlong bond displays in ChimeraX
Hi Matthias,
Maybe this helps on the molstar side (it actually does draw something similar to what you show in chimerax, but it is not exactly a bond but more of a connectivity hint):
```
Mol* never infers a covalent bond from sequence adjacency. Two subsystems, both gated on geometry:
Bond graph —
intra-compute.js:findBonds(). Bonds come only from struct_conn, from
chem_comp_bond (intra-residue only), or from a 3D neighbour search capped at
DefaultBondMaxRadius = 4 Å. O/P has no entry in __ElementPairThresholds, so
getPairingThreshold falls back to (1.52 + 2.0) / 1.95 ≈ 1.81 Å. A 168 Å pair never enters the candidate list.
Cartoon/polymer trace —
atomic-ranges.js:getAtomicRanges(). This is the direct answer. When
seqId === prevSeqId + 1, Mol* does not trust it, it verifies:
if (conformation.xyzDefined && !areBackboneConnected(riStart, riEnd, ...)) {
polymerRanges.push(startIndex, prevEnd - 1);
// add gap even for consecutive residues if they are not connected
gapRanges.push(prevStart, residueSegment.end - 1);
areBackboneConnected measures O3'→P for nucleic and requires
< 3 Å. Both joins fail, so chain M is split into three polymer ranges.
So: ChimeraX trusts the annotation, Mol* trusts the coordinates.
```
And regarding the model itself it just seems that you guys stitchhed the intron together awkwardly (which is not an indictment to you but to a labyrinthine cif format id say).
```
1. The intron SEQRES contains only the modelled residues
Every other polymer chain in 9S2E is annotated correctly:
entity_poly_seq carries the full biological sequence, and unmodelled residues just leave gaps in
label_seq_id. PRP8 declares 2335 and models 1979. Aquarius declares 1485, models 1369. Fifteen chains have author-numbering jumps, and in every one of them
except the intron the jump sits on a real label_seq_id gap — so every viewer breaks the chain correctly.
Chain M is the only chain in the whole entry where declared equals modelled: 61 of 61. So
label_seq_id runs 1..61 with no gaps, which is a positive assertion that these are 61 chemically consecutive nucleotides.
The corollary is the damning bit:
pdbx_unobs_or_zero_occ_residues has zero rows for chain
IN. There is nothing anywhere in the file recording that the intron is incomplete — except the author numbering, which is free-form metadata that software can't legitimately derive connectivity from. They deleted the evidence of the gaps by defining
the entity as "what I modelled" instead of "what the molecule is".
2. The three fragments are stitched in the wrong order
In label_seq_id order the fragments are auth 1–24, then 136–154, then 50–67. Biological 5'→3' would be 1–24, 50–67, 136–154. So even taking the concatenated sequence at face value, the declared
polymer direction says U154's 3' end is bonded to U50's 5' end — running backwards through the intron. That's why the phantom bond is the 168 Å one and not one of the shorter possibilities.
What it should have been
Either declare entity 13 with the full intron sequence (≥154 nt), leaving
label_seq_id gaps at positions 25–49 and 68–135; or split the three fragments into three separate
struct_asym entries so nothing claims they're covalently continuous. The rest of the entry already does the first thing correctly, fourteen times over — so this looks like the intron chain was built and named by hand, separately from the rest of
the deposition.
```
Best,
Artie
Dear Greg,
Thanks a lot for looking into this and for the reply. I was wondering if you had any guesses why the mol viewer does not show this bond?
In case anyone is interested, I attached a python script that detects and hides such bonds .
Best,
Matthias
So what you are seeing is not a bond, it is a cartoon connecting the disjoint parts of a single Intron. According to the mmCIF file's metadata, those two fragments are next to each other. That a bug in the mmCIF file. And ChimeraX
faithfully reproduces buggy data, otherwise, you'd never know. The PDB should have caught that error on deposition. It might be a bug in software used to refine the structure.
Please continue to report problems like this. mmCIF files are relatively new, and we are still learning about how
Analysis:
The entity_poly table says that Intron entities have 122 nucleotides. The atom_site table's label_asym_id and label_seq_id values indicate that there is one instance of the Intron entity with its first 61 residues present. Adjacent
nuceotides are implicitly connected. Gaps are indicated by gaps in the label_seq_id values, and there are none. As you observed, from the disjoint fragments in 3D, that information is not correct. Another clue is the auth_seq_values that range from 1 to
24 and 136 to 154. Since the 136 is more that 122, maybe it should really be two separate chains instead of one chain? Or maybe the numbering is wrong. Can't tell. Bad data.
I'd recommend contacting the author and/or the PDB to get it fixed.
HTH,
Greg
On 8/25/2026 4:34 AM, Vorländer,Matthias Kopano via ChimeraX-users wrote:
Dear ChimeraX staff,
For some mmCIFs, ChimeraX displays bonds that are physically unrealistic. For example, if you take PDB 9S2E ChimeraX draws a bond between residue /IN:52 and and /IN:154 (see screenshot).
The PDB mol viewer (https://www.rcsb.org/3d-view/9S2E)
does not display this
bond.
I noticed that structures in PDB format don’t show these bonds, so this is probably due to some connectivity records in cif format. I also have only observed this in nucleic acids, not proteins.
Is this a bug that could be addressed?
Thanks a lot and best wishes,
Matthias