Hi All, Amongst my colleagues (to whom I constantly evangelize Chimera) there is often an issue opening pdb and map files together. Specifically, sometimes the maps and pdb coordinates are not superimposed (often drastically). I have been able to reproduce the issue so let me explain what works and what doesn't. What works: If you take a pdb file and an mtz into Phaser (from the ccp4 suite) then refmac for rigid body refinement and convert the output mtz to a map using mapman it works. The pdb and map superimpose perfectly. What doesn't work: If you take a pdb file (of known correct solution but not transformed to the correct coordinates) and throw it into refmac (ccp4) and do some rigid body refinement and then convert the resulting mtz into a ccp4 map, the map is perfectly good (the statistics are identical to using the phaser placed model), but when opened in Chimera they do not superimpose. Both of the methods above appear valid as far as structure determination (R and Rfree are identical, etc) and I know coot will align the model and map and I believe pymol will too, though I don't use pymol personally so I cannot vouch for that. Is the correct transformation information hidden in a file somewhere so that Chimera can align the two files automatically. Often people skip the phaser step and drop the model right into refinement and then manually aligning in Chimera becomes difficult. Best, Wally Walter R.P. Novak, Ph.D. Postdoctoral Fellow Rosenstiel Basic Medical Research Center Brandeis University 415 South St. MS 029 Waltham, MA 02454-9110 Phone: (781) 736-4944 Fax: (781) 736-2405
Hi Wally, The CCP4 map file has alignment information in its header. The CCP4 maplib documentation describes the header: http://www.ccp4.ac.uk/html/maplib.html The problem could be that Chimera ignores the SKWMAT and SKWTRN fields. Could you send me a CCP4 map and PDB that align in COOT but not in Chimera and I will figure it out? Thanks, Tom
Hi Walter, With the help of your example CCP4 map I found that the problem was a heuristic used by the Chimera CCP4/MRC file reader to determine whether the (ncstart,nrstart,nsstart) header values are valid or appear to be uninitialized. If it found any n*start value to have absolute value larger than the original data size (mx,my,mz header parameters) then it considered the n*start position values out-of-range and probably uninitialized and used n*start values of (0,0,0). That messed up the position of the map you sent. I've changed this heuristic so that the n*start values only need to be less than 10 times the maximum data dimension to be considered valid. It would be nice to drop this heuristic altogether. Unfortunately some map files have uninitialized values that cause the map to be placed in deep space. The fixed Chimera code will be in the next snapshot (should be on the web on Friday from our automatic builds). If you wish to change your current Chimera code you can edit chimera/share/VolumeData/mrc/mrc_format.py replacing lines starting at line 87: if (nxs >= -mx and nxs < mx and nys >= -my and nys < my and nzs >= -mz and nzs < mz): from VolumeData.griddata import scale_and_skew self.data_origin = scale_and_skew((nxs,nys,nzs), self.data_step, self.cell_angles) else: self.data_origin = (0., 0., 0.) with limit = 10*max(max(mx,my,mz), max(self.data_size)) if [s for s in (nxs,nys,nzs) if abs(s) > limit]: self.data_origin = (0., 0., 0.) else: from VolumeData.griddata import scale_and_skew self.data_origin = scale_and_skew((nxs,nys,nzs), self.data_step, self.cell_angles) Make sure to keep the indentation as shown since that is important in Python. The above change is for Chimera 1.2422. Thanks for reporting the problem. Tom
participants (2)
-
Thomas Goddard -
Walter R.P. Novak