Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#2231 closed defect (can't reproduce)

mmCIF: new chain residues saved out of order?

Reported by: Tristan Croll Owned by: Greg Couch
Priority: minor Milestone:
Component: Input/Output Version:
Keywords: Cc: pett
Blocked By: Blocking:
Notify when closed: Platform: all
Project: ChimeraX

Description

Unfortunately I can't seem to replicate this now, but just flagging it up in case there's an obvious solution. While working on the model in #2184 I had to rebuild chain AA using chain AB as a template (all the A{ABC...} chains should be identical, but AA had a mismatch both in residue numbering and in sequence). I did this in the shell by first using matchmaker to find the best fit of AB to AA, then (from memory - code may not be exactly correct):

aa_atoms.delete()
amap = {}
for r in ab_residues:
    new_r = m.new_residue(r.name, 'AA', r.number)
    for a in r.atoms:
       new_a = m.new_atom(a.name, a.element)
       new_a.coord = transform*a.coord
       new_a.bfactor = a.bfactor
       new_r.add_atom(new_a)
       amap[a] = new_a

for b in ab_atoms.intra_bonds:
    m.new_bond(*[amap[a] for a in b.atoms])

Anyway, this worked fine in that the rebuilt chain behaved itself in visualisation and simulations, but when I saved the file to mmCIF the chain AA residues were written in random order. I *suspect* what happened is that ChimeraX was treating the chain as non-polymer (perhaps confused by the presence of a ligand with the same chain ID, combined with the non-ideality of the input mmCIF file itself)... as I said, though, I can't seem to replicate it.

Change History (3)

comment:1 by Greg Couch, 6 years ago

Cc: pett added
Resolution: can't reproduce
Status: assignedclosed

The mmCIF writer uses the structure's chains to figure out the polymers de novo, so if there is a mistake in creating the chains, the output will be bad. A ligand with the same chain id should not be a problem (Eric can correct me if I'm wrong). The chain id's end up as the auth_asym_id, not the label_asym_id.

comment:2 by pett, 6 years ago

By default, residues are ordered in the same order that they are created. If 'ab_residues' is a map or set, then that would be a problem. You either need to change your code to create the residues in chain order, or you need to call structure.reorder_residues(new_order) to set the order (of _all_ residues) afterward.

in reply to:  3 ; comment:3 by tic20@…, 6 years ago

Weird. I just got ab_residues by selecting chain AB in the command line, then using selected_atoms(session).unique_residues. I was under the impression that returned the residues in order (it usually seems to, anyway). Will be careful about this in future.
 

 


Note: See TracTickets for help on using tickets.