RSF Comprehensive Description
The Regularly Sampled Format (RSF) is a specific arrangement of information defined by the behavior of the implementation of the C API of Madagascar on a reference machine architecture with a reference version of a Linux distribution and associated dependencies. RSF is the way in which most Madagascar programs expect their input to be and in which they structure their output. Due to portability of code, an exact reference setup has not been specified, and it is expected that Madagascar programs will read and write in the same way on any machines on which the package was compiled successfully. While a intuitive introduction to RSF already exists, this document attempts to describe RSF in an exhaustive fashion, for the use of programmers attempting to interface Madagascar with other packages.
The RSF originated as a representation of a discrete set of values of a single-valued function defined on a n-dimensional space. A real-world example of this would be the values of pressure in a space-time volume through which an acoustic wavefield propagates. Each dimension of the space is either discrete and regular, or continuous, but sampled discretely and regularly. In this context, regularity is defined as the property of a set of reals or integers of being consecutive integer multiples of a finite quantity of the same kind of themselves. RSF can be visualized as "matrices with physical dimensions".
The physicality of dimensions, while useful for jargon, for explanations and for the definition of parameters below, is not compulsory. Ultimately RSF is just a sane way of storing n-d arrays on disk. Just like programming languages use intrinsic methods and user-defined procedures to work with arrays held in memory, Madagascar uses both programs in its main distribution and user-written programs to work with data stored in RSF. RSF datasets are just out-of-core arrays.
RSF "files" actually consist of a header file and a data file.
This file attempts to document the actual interface implemented in file.c; it is not a formal specification, and in the event of a disagreement the code should be taken as the official reference.
Associated with each such data file is a header file. The header file is 7 bit ASCII (UTF-7).
Lines with no "=" are considered comments and are ignored. Lines with more than one "=" are illegal.
Lines with a single "=", with no adjacent spaces, assign a value to an alphanumeric named variable
Textstrings must be delimited by pairs of quotes. Numerical values are subject to C's parsing rules.
"in=" parameter contains the fully qualified path to the relevant data and is required
"n#" (n1, n2, n3) etc. is the number of points in a dimension. n1 is the fastest direction (maps directly onto memory).
n1 must be specified. The size of the array is the product of all n# values with the size of the fundamental type
In addition to the above, many filters enforce the following conventions:
"d#" is the physical spacing in the respective dimension
"o#" is the physical origin in some absolute coordinate system of the respective dimension
Data files are rectangular arrays of data. The following data formats are supported
- ASCII (C-compatible input)
- XDR (device independent binary standard)
- native binary (default)
ASCII format is most useful for debugging, while XDR format is useful for portability across formats.
Performance is optimized for native format.
The following data formats are supported:
- unsigned byte
- int (native int)
- short (2 bytes)
- float (native float)
- complex (real, imaginary float pairs)
RSF files in streams
When a Madagascar program writes a RSF file to disk (i.e.: sfprog >file.rsf), it will create a header file and a binary file as described above.
If the output is to a stream, or if the parameter --out=stdout is passed to the program, then the program will write to the stdout stream the ASCII header, followed by the sequence of three special characters: EOL EOL EOT (\014\014\004), followed by the binary.
When a Madagascar program reads from the stdin stream, it expects either a EOF character indicating the end of the ASCII header (after which it transfers the stdin to reading from the binary cube), or a EOL EOL EOT sequence indicating that the data follows immediately on stdin.