id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc	blockedby	blocking	notify_on_close	platform	project
1233	Grid_Data applies rotation and skew in wrong order?	Tristan Croll	Tom Goddard	"Unless I'm missing something obvious...

The background is that while ChimeraX stores its volume data as (k,j,i), Clipper stores as (i,j,k). Previously I had a somewhat ugly approach on the C++ side to handle the copying, but to make things cleaner with the new bindings I decided to instead instantiate the Array_Grid_Data with rotation=((0,0,1),(0,1,0),(1,0,0)). That works fine for my default test case, but other maps were coming out with strange offsets to the model. Eventually pinned it down to cell angles - my default test is a perfect (90,90,90), and the failing maps are all non-orthogonal on at least one angle ((90, 100.12, 90) for the case I first noticed the problem on).

The upshot is that I think in Grid_Data.update_transform() the rotation and skew are being multiplied in the wrong order (r*s rather than s*r). Swapping the order as per the below puts everything back in registration:

{{{
  def update_transform(self):

    from chimerax.core.geometry import place
    saxes = place.skew_axes(self.cell_angles)
    from numpy import array
    rsaxes = saxes*array(self.rotation)
    tf, tf_inv = transformation_and_inverse(self.origin, self.step, rsaxes)
    if (self.ijk_to_xyz_transform is None or not tf.same(self.ijk_to_xyz_transform) or
        self.xyz_to_ijk_transform is None or not tf_inv.same(self.xyz_to_ijk_transform)):
      self.ijk_to_xyz_transform = tf
      self.xyz_to_ijk_transform = tf_inv
      self.coordinates_changed()
}}} 

 "	defect	closed	major		Volume Data		not a bug						all	ChimeraX