[Feature request]: assign Qscore as atom attributes

[kvr2007]

Hello!

First of all, many thanks for putting this plugin together! It was annoying that previously one had to use the "old" Chimera to calculate the Q-score. Also, the plot with all residues is very useful.

I was wondering if the computed Q-scores can be assigned to individual atoms? ChimeraX has rich support for custom attributes using setattr command:

https://www.cgl.ucsf.edu/chimerax/docs/user/commands/setattr.html

This way this information can be stored directly in the model, and one could use the Render by attribute tool to visualize the Q-score. Also, since multiple attributes can be defined, one could switch between backbone and side-chain Q-score.

Alternatively, one could create a new PDB file where the per-residue Q-score is written into the B-factor column. I think that's how the original Qscore plugin worked.

[tristanic]

That's a great idea, and you're right - it's not horribly difficult in principle to do this. The reason I hesitated and ultimately didn't do it in the original release is that I was worrying (perhaps overly much) about a few of the potential complexities:

• how to handle subsequent atom movements (probably best to wipe all scores if any atom positions change - could wipe just the moved ones, but that approach gets very messy very fast)
• what of the hypothetical scenario where the user wants to compare Q-scores for one model against multiple different maps? Writing the scores as atom/residue properties loses the information regarding which map the scores were calculated against (although I suppose the identity of the currently-used map could be assigned to a structure-level property)

I'm open to suggestions, but unfortunately my time for coding is a bit limited lately so it might take me a while to get to actually implementing anything.

On Thu, Aug 1, 2024 at 11:17 AM kvr2007 @.***> wrote:

Hello!

First of all, many thanks for putting this plugin together! It was annoying that previously one had to use the "old" Chimera to calculate the Q-score. Also, the plot with all residues is very useful.

I was wondering if the computed Q-scores can be assigned to individual atoms? ChimeraX has rich support for custom attributes using setattr command:

https://www.cgl.ucsf.edu/chimerax/docs/user/commands/setattr.html

This way this information can be stored directly in the model, and one could use the Render by attribute tool to visualize the Q-score. Also, since multiple attributes can be defined, one could switch between backbone and side-chain Q-score.

Alternatively, one could create a new PDB file where the per-residue Q-score is written into the B-factor column. I think that's how the original Qscore plugin worked.

— Reply to this email directly, view it on GitHub https://github.com/tristanic/chimerax-qscore/issues/5, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFM54YFLGHQ4TELMRZNKCPTZPIDKDAVCNFSM6AAAAABL2HXOR2VHI2DSMVQWIX3LMV43ASLTON2WKOZSGQ2DEMBWG43TGOA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

-- Altos Labs UK Limited | England | Company reg 13484917   Registered address: 3rd Floor 1 Ashley Road, Altrincham, Cheshire, United Kingdom, WA14 2DT

[kvr2007]

• how to handle subsequent atom movements (probably best to wipe all scores if any atom positions change - could wipe just the moved ones, but that approach gets very messy very fast)

From my perspective, validation with Q-score is typically done on models that are completed, so it is unlikely that atoms have to be moved. Computation of the Q-score also takes time, so yes, live computation is impractical.

• what of the hypothetical scenario where the user wants to compare Q-scores for one model against multiple different maps? Writing the scores as atom/residue properties loses the information regarding which map the scores were calculated against (although I suppose the identity of the currently-used map could be assigned to a structure-level property)

That's an interesting use-case! If I had to do such a thing, I would just export a CSV file for each map and then build a scatter plot or a difference plot to see which residues differ in the Q-score.

I'm open to suggestions, but unfortunately my time for coding is a bit limited lately so it might take me a while to get to actually implementing anything.

Taken the considerations above, I would suggest to add a tick-box that would add the Q-score as an attribute of atoms rather than doing this by default. I think other tools in Chimera(X) follow a similar pattern.

On a side note, it may be also helpful to expose the CSV export functionality in the GUI.

I am familiar with ChimeraX and PyQt, so I'll try to prototype this functionality and send a pull request :)

[tristanic]

These are all sensible thoughts - and thanks very much for the offer to have a go at it! Some quick thoughts:

• with a little extra code in the top-level init.py (https://github.com/tristanic/chimerax-qscore/blob/main/src/__init__.py) you can pre-register attributes with ChimeraX allowing you to assign values in pure Python rather than using the setattr command. See https://github.com/tristanic/isolde/blob/eeda514a3399a350d637814ec3d7062a29b4723b/isolde/src/__init__.py#L62 for example. If you do e.g.

  from chimerax.atomic import Atom
  Atom.register_attr(session, 'qscore', 'qscore', attr_type=float, can_return_none=True)

  ... then the Atom.qscore attribute will always be present and will save with sessions, and you can assign values using pure Python, e.g.:

  for a,score in zip(atoms, scores):
  a.qscore = score

• The reason I originally implemented this in ChimeraX (and did my best with accelerating it) was to apply it as an aid for finding potentially poorly-fitted regions to guide rebuilding in ISOLDE. While it's nowhere near fast enough to use live, I think the current version is fast enough to be useful as a tool to be used sporadically throughout the model building process. While I'd love to see another order-of-magnitude (or two) speedup, that'd be a much bigger effort (probably involving porting the whole thing to the GPU, for a start).