The data structures which can be represented using the DX data model include:
In the first case the dependent variable (which is the quantity to be visualised), perhaps for example, temperature, is sampled in a regular grid inside some region defined with the independent variables as axes. Usually the independent variables will be positions in two, three or higher dimensions. Typically inside your own programs such data would be represented as an array of appropriate dimensionality. The second and third cases are generalisations of the first and can be ignored for our present purposes. The fourth case corresponds to particle (or catalogue) data. Here each point is simply a point in an assemblage or cloud of points; there is no connection in terms of either the independent variables (positions) or the dependent variable between the points. An example might be a simulation of a globular cluster where each data point corresponds to a separate star following its own orbit inside the cluster.
Any of the four cases can occur with any dimensionality: one, two, three and higher dimensional data can be represented. Similarly all the usual data types are available: integer, real, double precision, complex etc. The dependent quantity may be a scalar (such as temperature, pressure or energy) or a vector (such as velocity or momentum).
The fundamental entity in the DX data model is an object. Data are represented by the same set of objects both when they are resident in memory when DX is running and when they are stored in native format disk files7. There are several sorts of objects. For the present purposes the most important type of object is the field; usually each separate dataset will be represented as a single field8.
A field consists of an arbitrary number of components and each component itself has a number of attributes. This hierarchy is illustrated in Figure 18.
field |
component 1 |
attribute 1 |
attribute 2 |
. |
. |
component 2 |
attribute 1 |
attribute 2 |
. |
. |
component 3 |
. |
. |
There are many different types of component. Some are mandatory, but most are optional. Only a few of the more common ones are relevant to the present discussion. They are listed in Table 1 and described below.
Name | Mandatory? | Comments |
positions | ∙ | position of each datum |
data | ∙ | value of each datum |
connections | relation between data points | |
box | bounding box for positions in the field | |
Components can have attributes associated with them. Attributes are additional items of information describing some aspect of the component. For example, the dependency attribute, ‘dep’, identifies another component on which the component depends; the ‘data’ component may depend on either the positions or the connections component, depending on circumstances. Alternatively the component ‘ref’ indicates that a component refers to another component. Typically the connections component will have a ‘ref’ of ‘positions’, indicating that the connections refer to the positions.
The connections component prescribes to DX how to perform interpolation between neighbouring grid elements. It describes the logical connectivity between adjacent neighbours in a grid. For example, the interpolation could be performed linearly along one of the axes, or bi- or tri-linearly along two or more axes simultaneously.
The connections component is implemented as an array. Each point in the positions component is given an ordinal number (starting at zero). The connections array comprises a ‘list of lists’ of numbers in which each entry represents the ordinal values of the points that are to be connected, listed in the order that they are to be connected.
You will not normally need to be concerned with the full details of the connections component. For a regular grid it can be created automatically when the data are imported into DX and represented compactly using a path or mesh array.
Fields representing particle or catalogue data where there are no logical connections between elements in the positions component will not usually have a connections component (again think of the example where each point represents a star orbiting in a globular cluster).
For a field of gridded data (it is easier to think of a regular grid, though the argument applies equally to an irregular grid) there are two ways in which the dependent variable can relate to the elements of the grid.
The practical difference between the two cases is the way in which values for the dependent variable are computed at positions intermediate between grid points.
The dependency attribute, ‘dep’, of the data component will be set to ‘positions’ if the data are position dependent and to ‘connections’ if they are connection dependent.
Before you input data to DX you must decide whether they are position dependent or connection dependent. Position dependent data are probably more common in astronomy.
7It is also, of course, possible to input files written in a wide variety of other formats; see Sections 5 and 6 for some examples.
8This usage of the term ‘field’ corresponds to its usual meaning in physics rather than in computing. For example, a DX field may represent a three-dimensional grid holding a set of samples of the velocity field throughout some volume. This usage is quite different from the usual meaning in computing: a predetermined section of a record allocated to the storage of a particular data item. Anyone used to the computing terminology should particularly beware of this different usage.
9Strictly speaking this array, and other arrays in components, are themselves DX objects of type array. However, this complication is not important to the present discussion and it is adequate to think of the component as simply an array of numbers.