2,684
edits
Eiger: Difference between revisions
Jump to navigation
Jump to search
no edit summary
No edit summary |
No edit summary |
||
| Line 4: | Line 4: | ||
# It is advisable to use the most recent 64bit version of XDS (since version Oct 15, 2015 the 32bit versions are no longer distributed anyway). The idea of the new framecache in XDS is that RAM is used to save on I/O. To this end, XDS tries to store NUMBER_OF_IMAGES_IN_CACHE=DELPHI/OSCILLATION_RANGE images in memory. Each frame is stored as (number of pixels)*(4 bytes) which means 72 MB in case of the Eiger 16M. As an example: if DELPHI=20 and OSCILLATION_RANGE=0.05 your computer has to have 400*72MB = 29GB of memory (plus some more for the program and the operating system). If it has not, the fallback is to the old behaviour of reading each frame three times. | # It is advisable to use the most recent 64bit version of XDS (since version Oct 15, 2015 the 32bit versions are no longer distributed anyway). The idea of the new framecache in XDS is that RAM is used to save on I/O. To this end, XDS tries to store NUMBER_OF_IMAGES_IN_CACHE=DELPHI/OSCILLATION_RANGE images in memory. Each frame is stored as (number of pixels)*(4 bytes) which means 72 MB in case of the Eiger 16M. As an example: if DELPHI=20 and OSCILLATION_RANGE=0.05 your computer has to have 400*72MB = 29GB of memory (plus some more for the program and the operating system). If it has not, the fallback is to the old behaviour of reading each frame three times. | ||
# Dectris provides [https://www.dectris.com/news.html?page=2 H5ToXds] (Linux only!) which is needed by XDS. H5ToXds should be copied to e.g. /usr/local/bin/H5ToXds.bin - note the .bin filename extension! As an alternative, one could use GlobalPhasing's hdf2mini-cbf program or, from http://www.mrc-lmb.cam.ac.uk/harry/imosflm/ver721/downloads, the miniCBF-OSX or miniCBF-Linux program. | # Dectris provides [https://www.dectris.com/news.html?page=2 H5ToXds] (Linux only!) which is needed by XDS. H5ToXds should be copied to e.g. /usr/local/bin/H5ToXds.bin - note the .bin filename extension! As an alternative, one could use GlobalPhasing's hdf2mini-cbf program or, from http://www.mrc-lmb.cam.ac.uk/harry/imosflm/ver721/downloads, the miniCBF-OSX or miniCBF-Linux program. | ||
# For faster processing, the shell script below should be copied to /usr/local/bin/H5ToXds and made executable (<code>chmod a+rx /usr/local/bin/H5ToXds*</code>). This script ''also'' uses RAM to speed up processing; it uses it for fast storage of the temporary file that H5ToXds/miniCBF/hdf2mini-cbf writes, and that each parallel thread ("processor") of XDS reads. The amount of additional RAM this requires is modest (about (number of pixels)*(number of threads) bytes). | # For faster processing, the [[Eiger#A_script_for_faster_XDS_processing_of_Eiger_data|shell script]] below should be copied to /usr/local/bin/H5ToXds and made executable (<code>chmod a+rx /usr/local/bin/H5ToXds*</code>). This script ''also'' uses RAM to speed up processing; it uses it for fast storage of the temporary file that H5ToXds/miniCBF/hdf2mini-cbf writes, and that each parallel thread ("processor") of XDS reads. The amount of additional RAM this requires is modest (about (number of pixels)*(number of threads) bytes). | ||
A suitable XDS.INP should normally be written by the beamline software; [[generate_XDS.INP]] does not (yet) write it. The XDS_from_H5.py script (below) can be used if XDS.INP is not available. | A suitable XDS.INP should normally be written by the beamline software; [[generate_XDS.INP]] does not (yet) write it. The XDS_from_H5.py script (below) can be used if XDS.INP is not available. | ||
| Line 25: | Line 25: | ||
When I repeat this, I get | When I repeat this, I get | ||
Total elapsed wall-clock time for XDS 128.3 sec | Total elapsed wall-clock time for XDS 128.3 sec | ||
Repeat once again: | |||
Total elapsed wall-clock time for XDS 129.3 sec | Total elapsed wall-clock time for XDS 129.3 sec | ||
So a bit of cache-warming helps, but not much. This machine has 64GB RAM. From the output of "top", the highest memory usage occurs during INTEGRATE, when each of the mintegrate_par processes consumes up to 7.4% of the memory. In other words, in this way less than 20GB of total memory are used. "top" shows a CPU consumption around (on average) 4 times 650%. | So a bit of cache-warming helps, but not much. This machine has 64GB RAM. From the output of "top", the highest memory usage occurs during INTEGRATE, when each of the mintegrate_par processes consumes up to 7.4% of the memory. In other words, in this way less than 20GB of total memory are used. "top" shows a CPU consumption around (on average) 4 times 650%. | ||