Writing ``Raw'' Frame Files

The first step is the generation of the raw data that are the source of each frame of the animation. This involves combining a ``data extraction'' subroutine with existing code so that the resulting code produces the necessary data files. This is depicted in the top third of the flow chart of Fig. 1. The raw data is written to output files so that the actual rendering of an image can be done either in a separate post-processing stage or by a separate process that runs concurrently with the data-generating code. In this way, the amount of effort needed to ``instrument'' existing code is minimal---only the data extraction subroutine need be spliced into existing code. We have found it most convenient to place the raw data for each frame in separate output files, i.e., one output file per frame. The raw data are stored directly in binary format (instead of formatted ASCII values) to save space---each single-precision field value is stored using only four bytes. These raw files have a common ``base name'' in addition to a postfixed unique numeric designator that is set off from the base by a period. For example, a collection of one hundred raw data output files with the base name frame would consist of the files frame.1, frame.2, ... frame.100.

Although the raw data files must be consecutively numbered, one does not necessarily want to generate an output file at each distinct value of the ``driving parameter'' of the process. For example, in some instances one would not want to generate an output file at each time step in an FDTD simulation since there may be too little change from one frame to the next. A more reasonable approach might be to generate a frame after every two (or more) time steps. The offset between times at which output is produced is something that is best left to the individual user. Furthermore, it may also be desirable to subsample the spatial grid. For example, it may be best to only display the field associated with every second grid point if the grid is very dense. On the other hand, for grids that are very sparse, to avoid excessive graininess in the output image, it may be desirable to interpolate additional output (or image) points.

Since the details of any data extraction subroutine are so closely linked to the particular application, we will merely describe the minimal set of tasks it should fulfill. The data extraction subroutine should:

1. Open an output file for each frame of data. The file names have a unique ``base'' name and a postfixed frame number. Although not absolutely necessary, for the sake of efficiency, the output files should be opened for binary output (as opposed to formatted ASCII data).
2. Write the number of columns and rows of output (to be consistent with other data, these data are written as single precision real numbers).
3. Write the data that corresponds to each pixel of the image. Data is written as binary single precision real numbers. The order is such that the first point of data will correspond to the pixel in the upper-left corner of the image, the next point will appear to the right of that, and so on, until the first row is complete. The next data point corresponds to the first pixel in the second row, etc., proceeding in the direction in which one reads English text (left to right, top to bottom).
4. Finally, in many instances it is useful to have the data extraction routine record (and later report) the largest output value. Although this value is not strictly required, it can be used to normalize the images so that the colors in each image are rendered with respect to the maximum value found in the entire collection of images. Subsequently, this value will be referred to as .

This set of tasks is fairly straightforward and should be easy to implement for most programmers. However, two aspects of this list that may be somewhat challenging, especially to Fortran programmers, are the handling of binary data and the creation of a sequentially numbered set of output files with a common base name. Those who would benefit from an example data extraction routine are directed to Appendix A where a routine is given that, in addition to accomplishing the above tasks, permits the subsampling of any rectangular subsection of a two-dimensional grid using arbitrary offsets (i.e., arbitrary strides).