Map real/reciprocal space roundtrip issues #133
Description
This is a consolidation of issues #73 #123 and #124, which all have the same simple underlying cause.
Typically, reciprocal space maps (complex SFs) are truncated with a spherical cutoff. By contrast, real space maps lie on a parallelepiped array, the Fourier conjugate of which encloses the corresponding spherical region of non-zero SFs. The SFs outside the spherical region are simply zero, and do not contribute to the Fourier synthesis. If the map is oversampled, then the zero region extends beyond the sphere into a "zero-padded" volume.
That's all basic.
Therefore, if a spherically cut dataset is transformed to real space, modified, and then transformed back to reciprocal space, information will be lost if the original spherical cut is reapplied. This is common in meteor and is the root cause of all the issues above.
gemmi complicates things, because it was not designed with this in mind. So while the methods gemmi has to transform from SFs in MTZs to CCP4 maps are usually convenient, in this case they are decidedly not.
Design goals
- Numerical stability. Conversion between real <> reciprocal space should be stable. To achieve this, we need to keep non-zero SFs when converting from real space maps, even if they are outside the original spherical cutoff.
- Simplicity in the user interface. Map oversampling should work as expected & grid spacings/resolution cutoffs should not be required by the user.
Things to do to achieve these goals
- implement a
gemmi-free to/from numpy methods forrsmap.Map - base the to/from gemmi methods on the numpy ones, rather than the other way around
- thereby remove all instances of
high_resolution_limit(Map.from_3d_numpy_mapandMap.from_ccp4_map) - ensure numerical stability in
test_ccp4_map_round_trip - add a variant of
test_ccp4_map_round_tripthat begins with a parallelepiped array, e.g. fromsfcalc.structure_file_to_calculated_map(...)