[Chimera-users] Map Oddities

[Thomas Goddard]

Hi Albion,

  When you are running Chimera and it opens a Python code file with
suffix .py and there is an older byte compiled version of the same
file with suffix .pyc then Python automatically recompiles the .py
file and you should see that the date on the .pyc file is updated.
You never need to compile Python files by hand.

  Here are 3 ideas about how to make some programs that read MRC maps
establish equivalent map positions.

  As I mentioned in my previous email some programs may fail with certain
maps to associate the x,y,z axes with the correct data axes.  And some may
ignore all header info about positioning.  So there are alot of different
cases.  I'm only going to make suggestions for the simple problems.

  One idea is to have Chimera print out the difference between the origin
that a crystallography program would use versus the MRC 2000 origin.
You could insert a little code in the Chimera mrc_format.py file to
print this difference for MRC 2000 files.  Specifically after the line

      self.data_origin = (v['xorigin'], v['yorigin'], v['zorigin'])

add lines

      # Print difference between crystal and mrc 2000 origins
      ncs_nrs_nss = v['ncstart'], v['nrstart'], v['nsstart']
      nxs, nys, nzs = ncs_nrs_nss[xa], ncs_nrs_nss[ya], ncs_nrs_nss[za]
      from VolumeData.griddata import scale_and_skew
      x0,y0,z0 = scale_and_skew((nxs,nys,nzs), self.data_step,
                                self.cell_angles)
      print 'Origin difference ', self.name, '=',
      print x0 - v['xorigin'], y0 - v['yorigin'], z0 - v['zorigin']

The origin difference will be printed to the Chimera reply log and you
can somehow apply it in other programs.

  A second idea is to try to modify the MRC 2000 map header so that
the crystal origin is the same as the xorigin, yorigin, zorigin header
values.  This is generally not possible since the former uses integers
while the latter uses float values.  But if you don't care where the
origin is as long as all programs agree, you might adjust xorigin, yorigin
and zorigin to match the crystal origin.  You would need some simple
program to modify the map header.

  A third approach is to modify Chimera mrc_format.py so it never uses
the MRC 2000 xorigin, yorigin, zorigin.  If Chimera always uses the crystal
origin that would probably more often agree with other software packages.
I would recommend against this approach.  You will later install a new
version of Chimera without the modification and your fit PDB models will
no longer align with their maps and you will probably forget why and scream.

	Tom



> From: Albion Baucom <baucom at msg.ucsf.edu>
> Subject: Re: [Chimera-users] Map Oddities
> Date: Fri, 22 Sep 2006 17:12:51 -0700
> To: Thomas Goddard <goddard at cgl.ucsf.edu>
> 
> Hi Tom,
> 	Im going to take this off list since my inquiries get more specific  
> now, but you are welcome to post this back to list if you think it is  
> within the scope of the Chimera Users list.
> 
> So, you were right. There is indeed a X, Y and Z origin field in the  
> map header. Thanks for pointing that out and giving me the code to  
> print those values to the reply log.
> 
> A quick question regarding my modification to the mrc_format.py. I  
> don't know Python very well yet, and am wondering what happens when I  
> modified the source code. The modifications worked of course, but  
> Chimera did not recompile the code into a .pyc file. When are  
> the .pyc files accessed?
> 
> OK, back to the original question :)
> 
> So, offhand, could you suggest a fix for me so that other programs  
> that use the "other" origin can interpret the data the same as  
> Chimera? Naturally what is going to have to happen is I will have to  
> translate the PDB file a set distance based on the discrepancy  
> between the origin conventions. I would like to do this translation  
> as accurately as possible.
> 
> What I noticed from an empirical re-docking of the PDB file into the  
> density in another program was it had to be moved approximately ~116A  
> in all 3 axes. This appears to be close to the following calculation  
> (for the x axis in this case)
> 
> ( | xorg | - xlen) + (xlen/2)
> 
> where xorg (-224) is the MRC2000 origin, and xlen (213.423) is the  
> xtal origin. In this case this comes out to be
> 
> (224.000 - 213.423) + (xlen/2) = 117.289
> 
> Applying this to the model as a translation in all 3 axes looks  
> almost exactly like what I see in Chimera.
> 
> Does this make any sense? This is all I could come up with that gave  
> an answer close to my empirical docking translation numbers.
> 
> Thanks Tom. I really appreciate your help.
> 
> Albion