MTZ files are not maps. They can usually be converted into maps, but
that depends on the type of information they contain. Coot lets you load
an mtz and immediately view a map, but only because it internally picks
the coefficients that you probably want to use and then internally
executes an inverse Fourier transform. To get a map you can access
voxel by voxel you will need the CCP4 program "FFT":
http://www.ccp4.ac.uk/html/fft.html
Once you have a map file, you can convert it to text using the CCP4
program MAPDUMP:
http://www.ccp4.ac.uk/html/mapdump.html
or perhaps MAP2NA4
http://www.ccp4.ac.uk/html/maptona4.html
However, both of these output only a few significant digits, which
invariably introduces round-off error. Some may argue that the extra
digits are not "significant" anyway, but round-off error is an insidious
beast, and once introduced it never goes away. If you don't believe me,
try rotating a PDB file of lysozyme through 100 full 360-degree
rotations in 1 degree steps with PDBSET. You will find that you do not
end up with the same structure you started with! It is RMS 0.1 A
different, with some atoms as much as 1 A out of place. This is not a
bug in PDBSET, it arises from the round-off error in the 3rd
"significant digit" of the coordinates accumulating with each round-off
event.
But I digress. The point is that in situations where you are going to
go back-and-forth between map an mtz more than once, or if you simply
don't know the magnitude of error that you are dealing with (a common
situation), then I recommend keeping round-off error to a minimum.
Internally, CCP4 maps are stored as 4-byte floats, which have about
seven significant base-10 digits. The full file format definition is here:
http://www.ccp4.ac.uk/html/maplib.html
Personally, I tend to read map values with the unix binary dump program
"od", which can be made to read 4-byte floats. It is simply a matter of
skipping the header, which is easily done by using MAPDUMP to tell you
how many grid points are in the file and subtracting 4* that number of
bytes from the file size. I wrote a little jiffy script for converting
a CCP4 *.map file into a PDB file with the density printed into the B
factor column here:
http://bl831.als.lbl.gov/~jamesh/map_noise/scripts/map2pdb.com
This script does introduce round-off error, but you can modify it as you
see fit. You will find, however, that the PDB file produced this way is
pretty huge.
I should warn you that you will find that the "nearest" map grid point
is not a very good approximation of a given point of interest (such as
the center of an atom). What you might want to do is interpolate
between nearby map grid points, possibly even doing a cubic spline
interpolation in three dimensions. This feature cannot be found in the
CCP4 suite, but is available in the RAVE suite from Uppsala Software
Factory as the program MAPMAN:
http://xray.bmc.uu.se/usf/mapman_man.html
use the "peek" function in that program.
All that said, I caution you that integrating a "volume" from map values
is in general not a very good idea. More properly, the integral of
electron density over space is a "charge", and such integrals are very
sensitive to offsets. Offsets are dangerous because most maps are
calculated to have the sum all grid point values equal to zero. This is
simply because the F000 structure factor, which represents this sum, was
not measured. So, if you add "1" to all your map voxels, your integral
immediately becomes "n" times higher, where "n" is the number of grid
points. Yes, difference maps are supposed to be centered on zero, but
to what precision? You need F000 to be sure. One way of estimating
F000 was published recently:
http://www.pnas.org/content/111/1/237.long
However, when integrating density you also have problems with how far
away from your point of interest you should integrate. Too far and you
pick up a lot of noise, but too close and you get systematic bias.
Personally, I think the best way to integrate a map is by using
occupancy refinement. Essentially, if you have a noisy curve and you
want to integrate it, fitting a smooth function to that curve and then
integrating the curve itself is often a very powerful noise filter. The
calculated form factor for an atom has a well-defined integral (the
atomic number), it "automatically" defines the vacuum level of the map
by being zero far from the atomic center, it "automatically" subtracts
the density of neighboring atoms (if they are modeled in), and also
down-weights more distant voxels by an appropriate amount. That is, the
optimum noise filter is generally the same shape as the signal of
interest (sometimes called a Wiener filter, see the Numerical Recipes
book). So, if you fit a bunch of hydrogen atoms into your mystery
density (perhaps keeping the rest of the model fixed if you can) then
the sum of all those hydrogen occupancies is a very good estimate of the
number of electrons in the feature. What is the error bar? Try
jiggling the rest of the molecule and re-refining the occupancies. That
is at worst a lower bound for the total error. Do this 5-10 times with
different random number seeds and you will have a handle on the RMS
variation in your "measurement" of the charge. The END_RAPID.com script
available here:
http://bl831.als.lbl.gov/END/RAPID/end.rapid/Documentation/documentation.htm
can be useful for doing several parallel occupancy refinements with the
benefit of also adding noise to the data to get a more realistic error bar.
HTH
-James Holton
MAD Scientist
On 8/28/2014 7:49 AM, Alejandro Virrueta wrote:
Hello,
I am new to crystallography refinement, and I have a question (I'm
sorry in advance if it is a stupid one):
Is it possible to extract all the density values (observed and
model-computed) from an mtz file? I need this information in order to
quantify the volumes of the difference regions (peaks and holes).
Thanks,
Alex
