peptide ligand not labeled when only cartoon shown

[Elaine Meng]

Although I can select cartoon on the main protein and label all its residues, the ligand peptide does not get labeled when I do the same. Example, but maybe it's weird because ligand has same chain ID as the protein:

open 1t2w
... chain A has enzyme (residues 62-206) plus ligand (residues 331-335)
hide atoms
cartoon
label ligand
...no labels
sel ligand
label sel
... still no labels, but you can select some other part of the enzyme cartoon and label it. The ligand labels are only shown when the ligand atoms are shown, however.

Tested in UCSF ChimeraX version: 1.3.dev202110150902 (2021-10-15)

[Tom Goddard]

The residue labels get created for the ligand. But the ligand has polymer type PT_NONE and residue labels are not show for ribbons on polymer type PT_NONE because the code thinks no ribbon is actually rendered unless the polymer type is PT_AMINO or PT_NUCLEIC. So the first question is why is this ligand which looks to be standard amino acids not a polymer of type PT_AMINO. I guess this is because 1t2w has the ligands as all HETATM records.

The ribbon code I guess does not care about polymer type and just looks at whether the guide atoms are present with the right atom names.

In an ideal world the residue label drawing would instead show the label if the ribbon is rendered. But the code currently does not have a method to ask whether the ribbon is rendered. It only know if ribbon display is true or false, but that just indicates whether the residue should try to be rendered as ribbon, not whether it actually can be rendered as ribbon. Probably I should add a new method that says whether the residue actually has been rendered as ribbon. The trouble with that is that the code does not know if a residue was rendered as ribbon until it tries to make the ribbon. The labels may be rendered before the code tries to render the ribbon so the labels won't know if the ribbon was rendered. It may be possible to predict whether a residue will be rendered as ribbon, but it could be tricky -- it could depend if the neighbor residues have the necessary atoms. I think this is why there is no code to do this currently.

[Tom Goddard]

I am inclined to close this ticket without trying to fix it because the input data is pretty bad. The peptide ligand in the 1t2w mmCIF file actually has the 5 residues in 5 separate chains D,E,F,G,H and all atoms are HETATM. Those are the mmCIF chain identifiers. ChimeraX uses the author chain identifiers which put all 5 residues in chain A and I assume they were ATOM records when the author deposited them. So the mmCIF ids and HETATM type wants to claim the 5 residues are not a polymer but the author wanted to say they are a polymer. It would be reasonable to ask the PDB to fix this entry by putting all 5 residues in a separate chain (e.g. D) with ATOM records. As it is ChimeraX does something wacky with these residues -- ChimeraX recognizes them as a polymer but decides the polymer type is NONE (instead of AMINO). I guess it chooses that polymer type because they are HETATM records. If ChimeraX identified the polymer type as AMINO then the labels display correctly. The current label assumes polymer type NONE means this is not a polymer -- every residue has a polymer type but not all residues are in chains, and so non-polymer residues have type NONE. But the ribbon code uses ChimeraX "chains" and ChimeraX claims these 5 residues are a chain although it says polymer type is NONE.

At any rate I'd say this input PDB file has problems that are responsible for the missing labels, and it is going to be extremely rare, and would be somewhat difficult to fully fix in the code.

[Tom Goddard]

Bad input data. The PDB should fix this entry so the 5 residues are in one mmCIF chain as ATOM records, or ChimeraX should interpret it as a non-polymer as the current 1t2w PDB defines it and then no ribbon would be displayed. This is too rare a case of bad input data to justify the difficulty in putting in a code fix to handle it.

[Elaine Meng]

Understood.  It is the typical situation of trying to find tutorial systems and then running into several one-off problems.  Unfortunately, so far there have been half a dozen such problems for the only "good" (in terms of illustrating the problem area) system I've found, hence the multiple tickets filed recently.

[goddard@…]

We should report this to the PDB, asking them if they can make the 5-mer a proper polymer.  Maybe they will decide they really want it this way as a non-polymer.  If you do not want to report it let me know and I will.

[pett]

If you open it in PDB format, that peptide is not classified as ligand and is initially shown as cartoon. Labels on it (label :331-335) do show.

[pett]

It gets included in chain A.

[Elaine Meng]

I'm not sure I understand it enough to report it, so you could do it if you don't mind.  My guess as to why the peptide ligand was also in chain A but with different numbering than the enzyme was to make it clear which copy of the enzyme it goes with.  I.e. chain A is enzyme + ligand whereas chains B and C are unliganded copies of the enzyme.  It does not seem to fit with the usual pattern, however, so it may just be an oversight in their format regularization protocol.

[goddard@…]

Opening 1t2w in PDB format assigns the 5-mer polymer type as PT_AMINO while opening it as mmCIF assigns it as PT_NONE.  That is why the labels work for the PDB format file.  The PDB file lists the chain id as A and the atoms as HETATM.  The mmCIF file is messed up because they assign separate chain identifiers to each HETATM residue ignoring that this 5-mer is a single chain.

[goddard@…]

Ok, I reported the problem to the PDB.