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@msg.ucsf.edu> Subject: Re: [Chimera-users] Map Oddities Date: Fri, 22 Sep 2006 17:12:51 -0700 To: Thomas Goddard <goddard@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