Opened 11 years ago

Last modified 9 years ago

#69 closed defect

Atom spec parsing does not preserve model or chain order — at Version 5

Reported by: Tom Goddard Owned by: Conrad Huang
Priority: major Milestone: Alpha Release
Component: Command Line Version:
Keywords: Cc: meng@…, pett@…, scooter@…
Blocked By: Blocking:
Notify when closed: Platform: all
Project: chimera

Description (last modified by Eric Pettersen)

Tom G.:
Atom spec parsing of #1,​2 returns the models in reverse order 2,1. Need to preserve order for command "vop maximum #1,​2 scale 1.5,2.5" so the two scale factors are applied to the correct models.

Eric:
Also, chain order is not preserved. The command "mmaker #1/V/W to #2/W/V" matches V to V and W to W despite what is specified in the command because the order of the atoms/residues/chains given to the command callback are *both* ordered as V then W. Scooter needs this to work for stuff he's doing with RINalyzer, though I don't know if he needs it for the site visit. Maybe he can comment on that.

Change History (5)

comment:1 by Tom Goddard, 10 years ago

Another example, the map fitting command

fit #1.1 #1.2 #1.3 #1.4 #1.5 in #2 seq 3 res 5

is supposed to fit the maps in the order specified but the command gets them in order 1.5, 1.1, 1.4, 1.3, 1.2. The same unexpected order is produced by

fit #1.1-5 in #2 seq 3 res 5

comment:2 by Tom Goddard, 10 years ago

Resolution: fixed
Status: newclosed

Fixed. Order was following Models.list() ordering which came from an unordered Python dictionary.

comment:3 by Tom Goddard, 9 years ago

Resolution: fixed
Status: closedreopened

Only the case of a spec like #1 #2 #3 was fixed 4 months ago giving models in order. But the case #1,​2,​3 does not give the models in order. Elaine reports that

vop subtract #1,​3

actually subtracts #3 minus #1 because the atomspec parsing does not preserve model order and the command gets them in a list [model #3, model #1]. The order is in fact scrambled and depends on the dictionary order of models of in session.models.

From: Elaine Meng
Subject: Quick Start fixes
Date: July 12, 2016 at 4:20:33 PM PDT
To: Tom Goddard <goddard@…>

Hi Tom,
I was fixing up a couple small things in the Quick Start like the change in “vop zone” syntax. However, I became confused by the “vop subtract” result…. it doesn’t look like map 3 was subtracted from 1. It kind of looks the other way around. (instead of like the figure, it is a mesh in the same place as the groEL molmap). Maybe I messed something up, or did the order of which was subtracted from which change between Chimera1 and ChimeraX? Also it’s a mesh, not the solid surface shown in the image.

So I wasn’t exactly sure how to fix up that part. The command executes now (without the “true”) but result is not as expected, at least from the image.
Elaine

comment:4 by Tom Goddard, 9 years ago

Cc: meng@… added

comment:5 by Eric Pettersen, 9 years ago

Cc: pett@… scooter@… added
Description: modified (diff)
Priority: minormajor
Summary: Atom spec parsing does not preserve model orderAtom spec parsing does not preserve model or chain order
Note: See TracTickets for help on using tickets.