Although called "traces", the basic data units in the system are no longer fixed-length arrays. "Traces" can be f-k spectra, spectrograms (see spctrgr) graphic images, and arbitrary memory blocks.
Every trace consists of a data segment of an arbitrary-length and of a header. Data segments consist of several (usually 1) records. Even within one ensemble, traces can be of different lengths and formats. The header consists of an arbitrary number of entries. Every trace header entry has one of the following formats: INTEGER (32-bit integer), LONG (64-bit integer), FLOAT (32-bit), DOUBLE (64-bit), and CHARACTER of an arbitrary length. Note that these names for header entry formats are used during parameter input by all modules throughout the system. The number of data samples, sample interval, and the trace header format may vary from one module to another.
Traces may have a non-zero time start. For example, processing a wide-angle data set, it is convenient to store the traces in a time-reduced manner, saving up to 50% of disk storage and CPU time. To implement this, we store the beginning of each trace in the header entry TIMSTRT (see below).
Internally, each processing module always deals with two structured sequences of trace ensembles, one of them at the module's input and the second&127;at the output (). Ensembles are interconnected sequences of traces, typically (but not necessarily!) ended with a trace having the value of a predefined header LASTTR=1. A natural example of a trace ensemble is a set of records simultaneously acquired by a multicomponent instrument.
Every module has standard input and output ensemble sequences (). However, the modules can create their own ensemble sequences (), and some named ensemble sequences can be created by the user so that they are accessible to all modules (see modules store and load).
SIA supports a variety of system-wide databases existing independently of current data flow. These databases are loosely referred as tables. Tables can be viewed as sorted sequences of trace headers without data samples. The entire sequences of table records can be generated, processed and removed during Edit and Process phases.
Tables have symbolic names specified by the user, and user-defined formats. Once loaded, tables are visible for all modules in the same job, and many tables can be used in one job. A number of modules allow creation and modifications of tables, mathematical operations with their entries, plotting of the values, and exchange of the data between tables and trace headers. Travel time processing package is implemented using manipulations with tables.
Modules readtab and pritab convert tables from/to an easily readable ASCII format. Savetab and loadtab provide means for fast table storage and retrieval from binary files, with an arbitrary number of tables stored in each file. Starting with version 2.1, modules write and dskrd are able to save and retrieve tables from the same files in which data traces are stored. This feature is useful to maintain any dataset-dependent auxiliary information.
Two table formats are defined. Many modules can work with both formats. In both formats, tables contain an arbitrary number of argument header entries, and dependent header entries, or simply entries. All table entries have structures identical to those of trace header entries with symbolic names and formats described above.
The main free-table format is referred simply as TABLE (see the description of module readtab). In this format, all argument entries are sorted in the order of increasing values of the first argument. If the argument is a floating-point value, its values are compared with a certain tolerance, and thus the values lying in a certain range are considered to be equal. All entries with the same value of the first argument are sorted by the increasing values of the second argument, etc.
In the second table format, MAP, the table represents a multidimensional array of multi-entry records. The arguments assume arbitrary, but fixed values for all rows (columns, etc.) of the array; these values are listed in the table header. This type of table structure is mostly used to implement functions in multidimensional spaces, such as 2D or 3D velocity models defined on irregular rectangular grids.
All modules in a job can access a common set of parameters that are referred as "job parameters". Normally, these parameters can be used anywhere a numeric value is expected. Internally, these parameters are formatted as a trace header, and thus many operations associated with trace headers can be performed on this parameter area. The parameters are identified by their names, and mathematical operations can be performed on them using module parmath.
Job parameters allow to implement a more elaborate parameterization than it is possible with simple text substitutions. For example, one can supply a phase value, say, phi, through the command line (see *params), and to ensure that another two variables are always equal sin(phi) and cos(phi).
A special graphic subsystem was created, although not too well developed at present. With every job, a set of graphics objects is associated. It includes: color tables (standard and user-created), color palettes, line style lists, fill and pattern lists, and images. Images are sequences of internal instructions necessary to build a plot. These sequences are generated and updated by several modules, and may be plotted in several ways.
All images are recognized and accessed by their names, as defined by the user.
Modeling modules create their own structures containing several kinds of velocity models handled by other modules (ray-tracing, plotting, performing migration, etc.). As ensemble sequences and images, velocity models have names and can be accessed by all modules in the job. These models are created and maintained by specialized modules, using the standard SIA intermodular communication technique. At present, the system includes velocity models created by rayinvr, velmod, and velmod2.
Module nn creates an ANN that is assigned a name and can also be used in many ways throughout the system.