Annotations for MRC 2D-processing protocols and programs
By Vinzenz Unger and Anchi Cheng (C) Nov. 1998
Some general remarks: file extensions like “.img”, “.tap”, “.fft” etc. are suggestions and can be exchanged ad libitum. While unnecessary for the more general processing steps such as “TAPEREDGE”, pixel averaging or the calculation of a filtered image, it is highly recommended to keep the “command files” of processing steps like “JOBA”, CTF-correction and origin refinements for the individual images as permanent record. The same applies to scripts for merging and refinements of (beam)tilt parameter. Similarly, creating and keeping “logfiles” of the processing until the work on a particular image is finished helps to resolve potential problems. During the processing several temporary files are produced. These intermediates can take up large amounts of disk space. Therefore, it is useful to write these files to a “scratch area” and to delete files as soon as they are no longer needed. Some filenames used in the scripts are not unique. Consequently, if any of these files are to be kept they should be stored in a separate directory with unique filenames before processing the next image. Also, keep in mind that a mistake in a script for a second or third pass of processing may result in files being “picked up” from previous passes if common rather than unique file names were used. While an error message is written to the logfile if a program fails due to an incorrect input parameter, the following programs do not check that the input was actually created during the same pass, i.e. intermediates from previous passes may fill in if their filename matches the input requirements. However, if this happens the final result will usually look worse than the original input which should alert the operator to carefully check what happened.
A significant, albeit much shorter explanation can also be taken from the program headers or the general declarations of dimensions and parameter at the beginning of the programs. However, the comments are often minimal and a detailed study of the codes is most likely beyond the scope of newcomers to this area. Hence, the majority of explanations try to promote a basic understanding for the function and interaction between several of the most important parameter rather than giving an exhausting account of what precisely is happening inside the programs.