Renumbering residues

[Tristan Croll]

(Vaguely recall asking this once before, but can't find the ticket)

This will start becoming more important for me as ISOLDE moves into its next phase of supporting model *building* (rather than just *re*building). Case in point: yesterday a postdoc in Denmark emailed me to ask for advice on his in-progress new 3.4A crystal structure. Its state is representative of many models at the early stages of building: some portions complete and essentially correct, but other parts only traced as isolated poly-ala. Not only is the absolute numbering of these fragments unknown, but they almost inevitably start off with *internal* errors as well (i.e. too many/too few residues in a loop). Bringing it up to a final polished state will therefore require quite a bit of reordering and renumbering of residues.

I see that currently the number of a Residue is an immutable property of the C++ object. Are there big barriers to changing that? Or would it be better on my part to achieve renumbering by simply deleting the old residues and creating identical copies with the new numbers?

To be honest, now that I think about it the latter approach is probably best - since in some cases even the *chain* a given fragment belongs to starts out unknown. Still, would be interested in hearing your thoughts.

[pett]

This is ticket #919.

When designing ChimeraX's atomic architecture, it was basically the same as Chimera's in most areas. The significant enhancements were: better alt-loc handling; per-coordset attributes and pseudobonds; and C++ sequence/chain classes. Chimera was not used for structure determination/preparation, and so no eye for those type of capabilities went into the new design.

I guess my intention is to allow residue renumbering in a "bulk" fashion (residue list + a starting number) for efficiency and enforcing that no residues have the same number/insertion code/chain tuple. That's what Chimera supported.

For chains, I intend to allow you to change the chain ID of an entire chain to an unused ID. Again, what Chimera supported. Combining chains is different, and is currently supported only in the C++ layer as StructureSeq/Chain's operator+=. The combined chain will wind up with the chain ID of the left side of the +=. I could pretty easily expose that operator to the Python layer.

Would these capabilities sorta/kinda be enough? Would you need something to break chains apart?

[Tristan Croll]

That certainly sounds like it should be enough! Anything else I need I can almost certainly piece together from that, and the worst-case scenario is just creating copies with the new chain IDs/numbers - which really isn’t that terribly difficult.
 

 

[pett]

Implemented renumbering as Structure.renumber_residues(res_list, starting_number). This does not reorder the residues.

Will implement whole-chain ID changing next. Partial chain reassignment is not likely in the near term, and ticket #919 will remain open for that capability.

[pett]

Implemented (whole chain) chain ID changing via Structure.change_chain_ids(chains, chain_ids, non_polymeric=True). Non_polymeric controls whether non-polymers with the same original chain ID as a changing chain also have their chain ID changed.

Closing this and leaving #919 open for partial-chain chain ID changes.

[pett]

Despite saying that I was closing this ticket 3 weeks ago, it didn't actually get closed.