2 The Field: The AVS/Express Data Model

This chapter provides an overview of the AVS/Express Field data structure and discusses the subclasses of the Field class (which defines the Field data structure). Since most AVS/Express visualization techniques require that you import your data into a field, information on different types of data sets that you might use are also discussed.

As you learned in the previous chapter, you must import your data into AVS/Express and then pass that data into a visualization module in order to visualize data in AVS/Express. But what does it mean to import your data into AVS/Express? It means storing your data in a data structure, or AVS/Express group, called a field. A field is a general purpose data structure that supports many different types of data sets.

Data sets come in different "shapes" and have different levels of uniformity. For example, you can have scattered data, which can be represented as points in space with no regularity in the placement of each point. You can also have a very regular data set, such as an MRI image which defines density values at every pixel. The field provides an implicit description of the data to AVS/Express so that it can understand how to process and render the data.

To support the many different types of data sets that people want to visualize, AVS/Express provides the Field class (which defines the Field data structure) and a small number of subclasses of Field that support the different types of data sets. This chapter describes the general Field data structure, the different field types and the differences between these types.

Almost all of the visualization modules in AVS/Express support fields as input. Therefore, once you have converted your data into the appropriate Field structure, you can take advantage of the great number of AVS/Express visualization and rendering techniques without further conversion. Understanding the structure of fields will allow you to determine the best way to import your data into one. Understanding the Field data structure will also give you a better understanding of the operation of many of the visualization modules in AVS/Express work and will allow you to diagnose and correct problems in your visualization networks more effectively.

The information in the following sections is meant to give you a conceptual understanding of fields; it does not discuss the details of how to create fields. The next chapter provides details about actually creating fields and setting values in them. As you read the next few sections, keep in mind that you do not always specify every part of a field when you create one. Some parts of a field are optional and some parts are computed automatically by AVS/Express.

The grid defines a set of nodes, as locations in the data space. For example, the data space represents the the nodes might represent the locations

Depending on how regular the structure of your data is, you can define the locations by providing the coordinates of each node, or just the coordinates of the points that define the grid on which the nodes lie.

The node data is usually mapped to a color in the rendered visualization, so that changes in the data values correspond to changes in color.

Cells specify how to connect the nodes so that the grid can be drawn with lines or rendered as a surface. Sometimes AVS/Express can understand the cell structure from the type of grid you specify, and you do not need to specify the cells explicitly.

In addition to, or instead of, node data, you can specify cell data. Cell data is associated with the group of nodes that make up each cell. AVS/Express can use this data when rendering the surface of the grid, or to interpolate to the node data.

The data components (node data and cell data) are optional and you do not always need to explicitly provide cells.

This section describes the structural components of the AVS/Express Field data structure in more detail, and the fundamental principles of their use.

Like the bars, which can be defined by a position and a value, the basic components of a field are:

In an AVS/Express field, the set of points, or nodes, composing the data set is called a grid. In this example, the grid is a one-dimensional array of points, each of which corresponds to the type of measurment represented by the bar in the graph. You can also specify 2D or 3D grids.

The data values associated with the nodes are called the node data. In AVS/Express, the node data values are optional and are typically used to color objects. In this example, the node data represents the measurement for each bar and is used to set the height of the bar in the graph. It is also possible to have multiple data values, known as components of node data, associated with each node.

The type of grid and node data you use to describe your data depends on the nature of the data the way you want to visualize it. Consider the example of a volume of data representing values measured from air flowing over the wing of an airplane shown in Chapter 1 (see Slicing air flow data on page 1-4). The grid in this example is a three-dimensional grid representing the space above the wing in which the air flow measurements were taken. The nodes of the grid are uniformly spaced throughout the volume and represent the locations at which the air flow data was measured or can be calculated.

The node data contains multiple pieces of information for each node in the grid. Specifically, for each node, the data set contains values for density, x-momentum, y-momentum, z-momentum and stagnation. This data set therefore has five components of node data. Each component of node data (that is, each set of values) contains a value for each node in the data set. So if the air flow data set contains 10,000 nodes, there will be 10,000 density values, 10,000 x-momentum values, 10,000 y-momentum values and so on.

When the air flow is visualized the value of the data for one of the componets is mapped to a series of colors. Different data values appear as different colors within the volume. By studying how the colors change, the researcher can see how the data values for that component change as the air flows over the wing. For example, if the density value is being viewed, a sharp change in color signals an area in the volume in which the density changes suddenly.

Each data component in a field can contain scalar (single) or vector (multiple) values. The air flow data set contains scalar values for each of its five components. This data set could have been structured differently such that the x-, y-, and z-momentum values would be defined in one 3-vector. In that case, the data set would have contained three components of node data: a scalar density component, a 3-vector momentum component, and a scalar stagnation component.

It may seem that a set of nodes and its corresponding data values are all you need to visualize data, but they do not provide enough information to create a picture. Consider this "teapot". It consists of nodes and data, but no surfaces are drawn.

To create a picture that includes 3D surfaces, lines, and so on, you must provide connectivity information. This tells the renderer (the part of a computer graphics system that creates the picture from the data) how to connect the points in space and draw surfaces. Once surfaces are defined, the renderer can compute values for lighting, highlights (reflectiveness, and so on, making the set of points look like a real object. Providing connectivity information for the teapot data set enables the renderer to turn the data into a picture that looks like a teapot:

To specify the connectivity information that AVS/Express needs to create an object from the set of nodes you have provided, you specify cells sets. A cell is a geometric entity such as a point, a line, a triangle, or a hexagon. A cell set is a collection of such objects: a set of points, lines, triangles and so on. To provide connectivity information for the teapot, you must

The field that describes an object may be composed of more than one cell set. The teapot contains one polyline cell set and one polytri cell set. A polyline cell set is one in which the endpoint of a line is the start point of the next line. A polytri cell set is a triangle strip where two of the vertices of a given triangle are also part of the next triangle in the strip.)

Pictured below is a simpler example. It is a 3D, unstructured field shown within a bounding box to make it clearer that it is 3-dimensional:

You can see from its shape that it contains four triangles. So this field consists of one set of four triangle cells.

You have seen that each node in a grid typically has one or more associated node_data values. Cells can also have data values associated with them. A data set whose connectivity is provided explicitly as a set of quadrilaterals may have data values provided at every node, that is, at each of the four vertices of each quadrilateral, or it may have a single value provided for each quadrilateral as a whole. Data values associated with the cell as a whole are called cell data values. A field can specify node data or cell data or both (that is, both are optional).

Cell data can be used to represent such things as the amount of resistance on a surface or a saturation level across a whole area. They are values associated with the cell as a whole, not with the individual vertices which compose the cell.

Keep in mind that you must provide cell sets for certain fields and that both node data and cell data are optional.

You do not have to explicitly provide connectivity information for every data set. If your nodes are laid out in a somewhat uniform way, that is, your grid is structured, you can specify the dimensions of the grid and the location of only the nodes that are needed to define the grid, and AVS/Express can determine how to connect the nodes to create cells. However, if your data is irregular, that is, unstructured, like the teapot data, you must explicitly specify how the nodes connect to form cells. How to do this is discussed in a later section in this chapter.

The distinction between more uniform structured fields for which AVS/Express can generate the connectivity, and irregular, unstructured fields for which you must explicitly specify the connectivity is an important one. The degree of uniformity in your data space is one of the main characteristics distinguishing the kind of field you can select to represent your data in AVS/Express. This uniformity is expressed in a characteristic of a field called a mesh.

The cell sets together with the grid (the set of nodes) together make up the part of the Field known as the mesh.

The mesh component of the Field structure is composed of nodes (the grid) and cells made up from those nodes.

AVS/Express defines four main mesh types that differ in the amount of structure, or uniformity, they contain. The four mesh types (from most structured to least structured) are:

For unstructured meshes, you must provide the coordinates of every node in the data set explicitly. For structured meshes (which includes the Structured, Rectilinear, and Uniform types) AVS/Express can determine the location of some (or most) of the nodes based on the structure of the mesh.

For unstructured meshes, you must provide connectivity information explicitly by defining cell sets. For structured meshes, AVS/Express can supply the connectivity that is implied by the structure of the mesh.

The following table summarizes these differences for the different types of meshes in AVS/Express.


Mesh Type	Grid	Connectivity
Uniform	Supply max and min nodes only; AVS/Express computes the rest.	Implicit based on dimensions.
Rectilinear	Specify axis nodes. AVS/Express computes the rest.	Implicit based on dimensions.
Structured	Specify all nodes.	Implicit based on dimensions.
Unstructured	Specify all nodes.	Specify connectivity using cell_sets.

The three structured mesh types, structured, rectilinear, and uniform mesh, differ from an unstructured mesh in that they all specify dimensions. The dimensions of a mesh are the number of nodes along each axis of the grid. On the other hand, the structured meshes differ from one another in how much of the grid information must be provided explicitly to AVS/Express and how much can be implied from the structure of the grid.

Neither mesh looks particularly organized or structured, but there is an important distinction between the two. You cannot specify the dimensions for an unstructured mesh; but, you can specify dimensions for a structured mesh. In the example above, you cannot specify the number of nodes in any direction in the unstructured mesh. However, in the structured mesh above, the dimensions of mesh is 2x5 (2 nodes in each of 5 rows). Another structured mesh is shown below; its dimensions are 3x6:

The dimensions are an important component of a structured field -- they enable the renderer to use an implicit connectivity algorithm and compute the connectivity information so that it can create cell sets automatically.

You specify the dimensions of a field in an array. The array typically contains two or three elements. Each element specifies the dimensions along one axis. The dimensions array, {20, 40, 10} indicates a 3-dimensional field with 20 nodes along the x-axis, 40 nodes along the y-axis and 10 nodes along the z-axis.

A uniform mesh is the most structured of the structured mesh types. In a uniform mesh, the spacing of the nodes along each axis is uniform. That is, the distance between any two nodes along a given axis is the same. For example, every node along the x-axis may be two units apart, every node along the y-axis, one unit apart, and every node along the z-axis, ten units apart.

Since there is so much regularity in the spacing of the nodes in a uniform mesh, AVS/Express can compute quite a bit of the grid for you. Therefore, you specify only the coordinates of the minimum and maximum nodes in the data set. Given those two nodes and the data set's dimensions, AVS/Express can compute the location of all other nodes. Here is an example of a Uniform mesh:

The spacing along the x-axis is calculated as (x_max-x_min)/(dims[0]-1). The spacing along the y and z axes is computed by a similar formula.

A rectilinear mesh is one where you specify only the nodes along the axes. The nodes need not be uniformly spaced. The location of all the other (non-axis) nodes are computed by AVS/Express and are located at the intersection of the lines passing through the axis nodes. The mesh pictured below is a simple rectilinear mesh.

When you provide the grid information for this particular rectilinear mesh, instead of providing the coordinates of all 30 nodes in this data set, you provide only 11 coordinates; the locations of the 6 nodes along the x axis and the locations of the five nodes along the y-axis. The node at the origin is specified twice.

For a structured mesh, you must explicitly provide the coordinates of every node in the data set, because there is no uniformity in the placement of the nodes.

If you look at the 3x6 structured mesh above, you can see that there is no particular uniformity in the placement of the nodes. The first and second rows are close together; the last two rows are much farther apart. The first node in the third row is far from its neighbor in the second row, and the last node in that row is quite close to the second row.

You provide these node coordinates in an array. For each node in the data set, you specify the coordinates, which is usually an x, y pair or an x, y, z triplet of that node.

The unstructured mesh, often referred to simply as "mesh" is distinct from the other types of meshes in that it is the only mesh type that requires that you explicitly provide cell sets. This type of mesh does not assume any regularity in the placement of the nodes in the data set, so it is not possible for AVS/Express to determine how to connect the nodes together to create surfaces.

In more structured data sets, the connectivity can be computed by AVS/Express based on the order in which nodes are provided and the data set's dimensions. A simplistic way to think of this connectivity algorithm is that for each row, the first node connects to the second node, the second node connects to the third, and so on. Each node in a row also connects to the nodes directly above and below it in the rows above and below that row.

In order for AVS/Express to carry out this algorithm and automatically create cell sets, AVS/Express must know something about the "shape", or dimensions, of the data set. That is, in order to connect nodes in a row, the nodes must be organized into rows, and you must specify how many rows there are and how many nodes they contain. In an unstructured data set, such as the teapot, the nodes do not consistently form rows of the same size (same number of nodes), so it is not possible to specify dimensions. Therefore AVS/Express cannot create the cell sets; you must provide them.

If you are creating an unstructured field, you must provide the information about how to create one or more cell sets from the nodes. For each cell set, this includes the following information:

In an AVS/Express Field, the connection list is provided by one of two arrays: either a node_connect_list or a poly_connect_list. The node_connect_list contains a list of indices into the array of coordinates you specified when you defined the grid; the poly_connect_list is used when specifying poly cells, such as a polytri or polyline cell set.

Let's look at a simple example. Earlier, you looked at a 3D, unstructured field.

To provide this field's grid to AVS/Express, you must provide the array of coordinates defining the nodes. "Flattening out" this field, you can see the nodes that compose it and the x, y, z coordinate values of each node:

Node A(0), {-1,-1,1}, is the first node provided, node B(1), {1,-1, 1}, is the next node, and so on. Thus, the node_connect_list you would provide to create the four triangles would be:

As you can see, the more structured your mesh, the less information you must explicitly provide to AVS/Express. Depending on how much flexibility you have with your data set, this may be a consideration in determining what kind of mesh to use to store your data.

However, there is a more important reason to think about mesh types. Certain visualization techniques can only be applied to certain mesh types. Many visualization modules in AVS/Express operate on a field's dimensions, therefore they cannot be applied to unstructured fields (because unstructured fields do not have dimensions).

One such module is downsize; it produces a subsampled version of the input field that contains fewer nodes, so it is faster to render. If you specify a downsize factor of 3, downsize produces a field with one third the number of nodes in each dimension than were in the input field. downsize operates on a field's dimensions. A downsize factor of 4 on a field whose dimensions are 64x64x64 produces a field whose dimensions are 16x16x16. It would not be easy to carry out a downsize operation on an unstructured field. You could remove every nth node in the data set, but you do not know which cell that node is a part of and would therefore most likely wind up with a field that is not renderable (or one that creates a picture that is not very useful; think of a teapot with patches missing). For this reason, downsize accepts only structured fields as input.

Another module which operates only on structured fields is orthoslice; the orthoslice module produces a slice of the input field that is perpendicular to one of the coordinate axes. It does this by taking a certain row or column (or plane) of the data set, based on the dimensions.

Once you become more familiar with the different mesh types and you have an elementary understanding of what a visualization module does, in many cases it will be clear what kind of field a module will accept as input.

A mesh can be characterized by its computational dimensions (ndim) and physical dimensions (nspace).

The structured meshes used in the examples so far in this chapter are all simple, 2-dimensional meshes on a 2-dimensional page. AVS/Express distinguishes between the dimensionality of the object and the dimensionality of the space in which the object exists.

For example, the page of this book that you are reading is a 2D object. It has length and width but it has no "height", that is, you can think of it as infinitely thin. If this page is lying flat, then this 2D page exists in 2-dimensional space. 2-dimensional space describes the location of this page in space; you would need to provide only two coordinates for the four corners (nodes) of the page. For example, the corners are at {0,0}, {8,0}, {0,9}, and {8,9} (the book is 8x9 inches).

Now, take this page and bend it back as if you are going to turn the page. The page still has no "height" (you can still consider it infinitely thin), but it now exists in 3-dimensional space. To describe where the page is located in space, you now need to provide three coordinates (x, y and z) for each corner of the page. The object itself, the page of this book, has not changed; it is a still a 2D object, but it now exists in 3-dimensional space. Another way to think of this is that it still only takes two coordinates to locate a point on the bent page, but each point needs three coordinates to locate it in space:

Instead of saying 2-dimensional space and 3-dimensional space, the terms are abbreviated in AVS/Express to 2-space and 3-space, and the general term n-space is used to refer to these physical dimensions. When referring to the actual dimensions of an object, the terms 2D and 3D are used and these dimensions are referred to as computational dimensions.

Note: You are not limited to two or three physical dimensions or computational - dimesionalities of one or greater than three are also valid. AVS/Express can store values for dimensions greater than three, but there is no way to directly render it. When you want to display multi-variate data, you typically use multiple components of node data. This way, you can show one set of data values as colors, one set as z values (heights), one set as sphere radii and so on.

Pictured below are some examples of 2D and 3D objects in 2-space and 3-space. Note that a 3D object, by definition, must exist in 3-space. But a 2D object, such as the page of this book, can exist in either 2-space or 3-space.

As you start using AVS/Express, you will probably start referring to certain types of fields as images, volumes, and geometries. These terms are common in visualization; the examples below describe the fields that are associated with these terms.

An image is a 2-dimensional array of pixels. This corresponds to a 2D, 2-space uniform field in AVS/Express. The field is uniform because every node is evenly spaced, one unit apart. That is, all the pixels in the image are the same size. The pixel data values represent color. These are commonly single (scalar) values, 3-vector RGB (red, green, blue) values or 4-vector ARGB values (where A is for alpha, or opacity). This means that the field typically has a single component of node data with either scalar or vector values.

A volume is a 3D, 3-space field. Volumes can only be directly rendered using a technique called volume rendering. If you do not display the volume using volume rendering, you must first pass the data through a visualization module such as orthoslice or external_faces that produces a subset of the data that can be rendered by the viewer. Volume rendering is expensive and can be quite slow on large data sets, depending on the volume rendering algorithm used. For this reason, AVS/Express only volume renders data sets that are uniform and contain scalar byte values. So a 3D, 3-space, uniform, scalar byte field can be volume rendered. The hydrogen.fld data set provided in AVS/Express (which you can read using the Read_Field module) is an example of such a volume. Note that if you want to volume render this data set, you must make sure a volume rendering mode is enabled. (Select Object Editor->Modes->Volume Rendering from a viewer to enable volume rendering.)

A geometry is an unstructured 3-space field; the teapot (which you can read using Read_Geom) is an example of a geometry. This data set does not contain datamapped data values, which is why it is white when rendered (the teapot does contain node data, but its values are normals values and are not therefore datamapped). The math geometry (read in math.geo) does contain datamapped data values, so it is colored when rendered.

In addition to the standard cell sets described earlier, AVS/Express supports second order cells through the cell set objects Line2, Tri2, Quad2, Tet2, Hex2, Pyr2, and Prism2. These objects define mid-edge nodes, in addition to the corner nodes at each vertex of the cell, that can carry additional coordinate and data information. When passed a field that includes these cell set objects, the AVS/Express readers and Data Visualization modules recognize the second order data and read, visualize, and render the second order data correctly by the existing AVS/Express objects.

The 3D second order cells, Tet2, Hex2, Pyr2, and Prism2, are decomposed into Tri2 or Quad2 cells for rendering. The AVS/Express renderers use the additional coordinate information to more precisely draw the object's mesh. The additional data information supports the use of quadratic interpolation to render the cell's surface.

AVS/Express 3.3 includes two examples, Hex2 and Quad2 in the library Examples.Visualization, that demonstrate the use of second order data.

The second order cell sets Line2, Tri2, Quad2, Tet2, Hex2, Pyr2, and Prism2, extend the corresponding first order cells by adding a mid-edge node between each pair of corner nodes.

For example, the following diagram illustrates the nodes in the Tri cell data type. The numbering indicates the order of the nodes within a cell, that is, the order in which the nodes are specified in the node_data or coordinate_data arrays.

The mid-edge nodes can include both coordinates and data so they can located anywhere in between the corner nodes. The arrays of coordinate or data elements are extended to specify the additional nodes in the order numbered.

Objects to support each of these types can be found in the AVS/Express library found at Accessories.Field_Schema.Mesh_Schema.Cells_Schema. For details on using each of these types, see the corresponding reference page in the online documentation.

AVS/Express extends the AVS/Express field ASCII description file and the AVS UCD ASCII description file formats to support time dependent (multistep) data. (Binary file input is not extended.) For the ASCII description file, you can use these extensions to define steps in the data at which node data, cell data, and/or coordinate data can vary. The cell type, and the nspace and ndim values for the field cannot change. For UCD data, you can vary either the geometry, the data, or both at each step. For either type you can specify a string for each time step. The string will be displayed when the step is displayed.

The time dependent multi step data can be read in the AVS field file format into an AVS/Express network. The time dependent

Note: Time data, node data and coordinate data need not be in the same physical file.

The node data and coordinate data for each time step can vary. The cell type, nspace and ndim values for the field cannot change. For time dependent data, the reader displays controls in the application panel to :

The Examples.Visualization library in AVS/Express has Multistep_Field which uses time-dependent data.

Note: The following description assumes you are familiar with the definition of AVS/Express data using ASCII description files. For more information see, Read Field.

To support multistep data, AVS/Express changes the ASCII description file in the following ways:

If close = 1, which is also the default, the file being read for the information supplied by the specification is closed after reading the record. In this case, the next specification for this information must include skip and/or stride values that locate the information from the beginning of the file.

If close = 0, AVS/Express will preserve the file pointer at the end of the information pointed to by the current specification. The next specification for this information begins reading from this point. If your data is stored consecutively in a single file, you can use this token to avoid specifying the location of each record, and the data may be read in more quickly as well. The file pointer for the current specification is maintained independently from any other specification. I.e. each variable and coord are processed seperately.

If you have close = 0 at the end of "coord 1" and close = 0 at the end of "coord 2" the two positions will both be saved independently.

For step =1, skips for time, node and coordinate data are absolute from the starting of the file even when close=0. For the second and subsequent time steps the value of close value in previous step is used to interpret the behavior of skip forward of that particular data. I e. the close and skip values of the same step in any data specification do not interact.

Defines the number of steps. This is necessary when DO ~ ENDDO is defined. It can be omitted when DO~ENDDO is not defined. As long nstep is defined in the header portion, its actual position within the header can be anywhere.

Defines a string (time, step number etc.) that labels the step. If the string is defined in a separate file, then time file = is used. If the comment is defined directly then time value = is used. If the file in which the comment is stored is of type ASCII, then any character string can be read in.Note that there is no stride parameter.

Note: close is used not only for time specifications, but also for variable and coord. The default value is 1. When close = 1, the file is closed after reading the step. To read the next step, it is necessary to use descriptions such as skip and stride to define the position at which the next step begins from the beginning of the file. When close = 0, then the file is not closed after reading the current step. Instead the file pointer is preserved at the current location, and the location of the next step is specified relative to the position of this pointer.

Note: The close attribute only affect the time, variable, or coord specification in which it is given, even if all the information is stored in the same file. For example, if time and variable 1 for all steps is defined in the same file and close is set to 0 in both cases, then variable 1 is read relative to the last position of variable 1 in the previous step.

This token is required at the end of each step, including the last. This can be omitted if the number of steps is 1. Note: Here EOT is in upper-case characters but it is possible to use lower-case also. Other than the filename, the rest of the description is not case-sensitive.

A block of data enclosed in a DO - ENDDO pair is repeated until nstep steps are completed. Consequently, it is not possible to define another step after ENDDO. The nstep value must be defined in this case. You can enclose multiple steps in a DO - ENDDO block.

A set of data and the field file to read it is given below (filename: /tmp/sample.data):

data X Y Z
1
5.0 -2.0 -1.0 0.0
10.0 -1.0 -1.0 0.0
20.0 0.0 -1.0 0.0
25.0 1.0 -1.0 0.0
30.0 -2.0 0.0 0.0
40.0 -1.0 0.0 0.0
50.0 0.0 0.0 0.0
60.0 2.0 0.0 0.0
2
5.0 -2.0 -1.0 0.0
10.0 -1.0 -1.0 0.0
20.0 0.0 -1.0 0.0
25.0 1.0 -1.0 0.0
30.0 -2.0 0.0 0.0
40.0 -1.0 0.0 0.0
50.0 0.0 0.0 0.0
60.0 2.0 0.0 0.0
3
5.0 -2.0 -1.0 0.0
10.0 -1.0 -1.0 0.0
20.0 0.0 -1.0 0.0
50.0 2.0 -1.0 0.0
35.0 -2.0 0.0 0.0
45.0 -1.0 0.0 0.0
55.0 0.0 0.0 0.0
95.0 3.0 0.0 0.0

The following example illustrates the file specification to read the data given above when close = 1. (Note that close = 1 is the default and could be omitted from the specifications.)

# AVS field file
#
ndim = 2
dim1 = 4
dim2 = 2
nspace =3
veclen = 1
data = float
field =irregular
time file=/tmp/sample.data filetype=ascii skip=1 close=1
variable 1 file=/tmp/sample.data filetype=ascii skip=2 offset=0 stride=4 close=1
coord 1 file=/tmp/sample.data filetype=ascii skip=2 offset=1 stride=4 close=1
coord 2 file=/tmp/sample.data filetype=ascii skip=2 offset=2 stride=4 close=1
coord 3 file=/tmp/sample.data filetype=ascii skip=2 offset=3 stride=4 close=1
EOT
time file=/tmp/sample.data filetype=ascii skip=10 close=1
variable 1 file=/tmp/sample.data filetype=ascii skip=11 offset=0 stride=4 close=1
coord 1 file=/tmp/sample.data filetype=ascii skip=11 offset=1 stride=4 close=1
coord 2 file=/tmp/sample.data filetype=ascii skip=11 offset=2 stride=4 close=1
coord 3 file=/tmp/sample.data filetype=ascii skip=11 offset=3 stride=4 close=1
EOT
time file=/tmp/sample.data filetype=ascii skip=19 close=1
variable 1 file=/tmp/sample.data filetype=ascii skip=20 offset=0 stride=4 close=1
coord 1 file=/tmp/sample.data filetype=ascii skip=20 offset=1 stride=4 close=1
coord 2 file=/tmp/sample.data filetype=ascii skip=20 offset=2 stride=4 close=1
coord 3 file=/tmp/sample.data filetype=ascii skip=20 offset=3 stride=4 close=1
EOT

Note: The following description assumes you are familiar with the definition of the AVS UCD file format. For more information see, Section "Read UCD File Format" in the DV Toolkit.

Only the AVS ASCII UCD file format has been extended to support time-dependent data. UCD data is made up of geometry data describing the object's mesh, and data defined at nodes or cells. The time-dependent format allows you to define this for each time step.

The time-dependent file format, adds the following attributes to the UCD file format.

Lines beginning with # are comments and are ignored. However, no comments can be entered within the data description.

Number of steps. If this line is absent, the format is recognized as the existing UCD data format.

cycle_type can take three values: data, geom and geom_data. For each of these types, the data is ordered as given below:

Specifies the step number at the beginning of every step. For example, you must specify the first step as step1, the second step as step2 and so on. An optional comment on every step can be inserted after the step number though this is optional. The Read_UCD module outputs this comment and hence, it is possible to display this comment in the display window.

Specifies the number of nodes and the number of cells.When the type is geom or data_geom, these values are defined in every step. However, if the type is data, the values remain the same for all the steps and are defined only in the first step.

Specifies the node number and coordinates for each node. The node number is an integer. These numbers need not be continuous. However, the same number should not be repeated.

Specifies the cell number. This is an integer. These numbers need not be continuous. However, the same number should not be repeated.


Line	line
Triangle	triangle
Quadrilateral	quad
Hexahedron	hex
Prism	prism
Tetrahedron	tet
Pyramid	pyr
point	pt

Specifies the number of nodes in each cell. These numbers correspond to those defined by the cell type. See the figure in Using 2nd order cells for an illustration of how the nodes are numbered for each cell type.

Specifies the number of data elements for each node and each cell. When num_ndata is 0, <num_comp for node data>, <size_comp>,<node_comp_label>, <unit_label>, <node_id>, and <node_data> are omitted. When num_cdata is 0, the portion from <num_comp for cell_data> and <size_comp> to the next step describing cell data is omitted.

Note: In the current format, these attributes are specified in the header. The number of data for the model was also specified. However, in the new format this is omitted.

Specifies the number of components in the node data and the size of each component. The number of size_comp values to be defined is the same as the number of components. For example, if the node data has 2 components, one of which is a 3 element displacement vector and the other is a scalar denoting temperature, the values for these attributes are as follows: num_comp = 2 size_comp1 = 3 size_comp2 = 1 Hence, the num_ndata specified is the sum total of size_comp1, size_comp2......

Specifies the label for each component and the unit. The number of values specified is equal to the number of components. Use "," to separate the node_comp_label and the unit_label. Use a space character when you do not want to specify a label. However, in this case make sure you insert the "," in between.

Specifies the node number and the data and these values are specified for each node. The order in which node data is specified is derived from the cell type.

Specifies the number of components for cell data and the size of each component. This is specified in a manner similar to node data up to the next step as shown below.

# example of new ucd format
2
data
step1 comment (optional)
14 6
1 3.000000 0.000000 0.000000
2 2.897780 0.776457 0.000000
3 2.598080 1.500000 0.000000
4 2.121320 2.121320 0.000000
5 1.500000 2.598080 0.000000
6 0.776457 2.897780 0.000000
7 0.000000 3.000000 0.000000
8 3.600000 0.000000 0.000000
9 3.477330 0.931749 0.000000
10 3.117690 1.800000 0.000000
11 2.545580 2.545580 0.000000
12 1.800000 3.117690 0.000000
13 0.931749 3.477330 0.000000
14 0.000000 3.600000 0.000000
1 1 quad 1 8 9 2
2 1 quad 2 9 10 3
3 1 quad 3 10 11 4
4 1 quad 4 11 12 5
5 1 quad 5 12 13 6
6 1 quad 6 13 14 7
4 0
2 3 1
disp, mm
temp, degree
1 0.433090 0.000000 0.000000 1.0
2 0.417480 -0.040804 0.000000 1.0
3 0.372751 -0.080154 0.000000 1.0
4 0.303528 -0.114977 0.000000 1.0
5 0.214628 -0.141834 0.000000 1.0
6 0.111246 -0.158527 0.000000 1.0
7 0.000000 -0.164147 0.000000 1.0
8 0.444816 0.000000 0.0000000 1.0
9 0.421018 -0.021786 0.000000 1.0
10 0.357638 -0.054806 0.000000 1.5
11 0.272308 -0.099735 0.000000 1.5
12 0.180339 -0.146491 0.000000 1.5
13 0.089219 -0.181521 0.000000 1.0
14 0.000000 -0.194428 0.000000 1.0
step2 optional comment
4 0
2 3 1
disp, mm
temp, degree
1 0.879362 0.000000 0.000000 1.0
2 0.847907 -0.074771 0.000000 1.5
3 0.758743 -0.147751 0.000000 1.5
4 0.620941 -0.211376 0.000000 1.5
5 0.441610 -0.258455 0.000000 1.5
6 0.229843 -0.286550 0.000000 1.0
7 0.000000 -0.295792 0.000000 1.0
8 0.901270 0.000000 0.0000000 1.0
9 0.853196 -0.038875 0.000000 1.5
10 0.727523 -0.102175 0.000000 2.0
11 0.560769 -0.187785 0.000000 2.0
12 0.378478 -0.272793 0.000000 2.0
13 0.190488 -0.333520 0.000000 1.5
14 0.000000 -0.355280 0.000000 1.0

The following example illustrates the file specification to read the data given above when close = 0. This example also uses a DO loop.

# AVS field file
#
nstep=3
ndim=2
dim1=4
dim2=2
nspace=3
veclen=1
data=float
field=irregular
time file=/tmp/sample.data filetype=ascii skip=1 close=0
variable 1 file=/tmp/sample.data filetype=ascii skip=2 offset=0 stride=4 close=0
coord 1 file=/tmp/sample.data filetype=ascii skip=2 offset=1 stride=4 close=0
coord 2 file=/tmp/sample.data filetype=ascii skip=2 offset=2 stride=4 close=0
coord 3 file=/tmp/sample.data filetype=ascii skip=2 offset=3 stride=4 close=0
EOT
DO
time file=/tmp/sample.data filetype=ascii skip=8 close=0
variable 1 file=/tmp/sample.data filetype=ascii skip=1 offset=0 stride=4 close=0
coord 1 file=/tmp/sample.data filetype=ascii skip=1 offset=1 stride=4 close=0
coord 2 file=/tmp/sample.data filetype=ascii skip=1 offset=2 stride=4 close=0
coord 3 file=/tmp/sample.data filetype=ascii skip=1 offset=3 stride=4 close=0
EOT
ENDDO

The Express field has been extended to support time-dependent data. For unstructured and curvilinear meshes, coordinates, node data, and cell data now can be extended to contain steps of time data:

Time dependent coordinates are stored inside a new array of groups in the Grid hierarchy called "time_coordinates." New group objects, Time_Grid, Time_Grid_Struct, Time_Mesh, and Time_Mesh_Struct, have been defined to support the time-dependent data structures needed for each of the types of field structure: These objects extend their base objects, Grid, Grid_Struct, Mesh, and Mesh_Struct in the following ways:

Time dependent node data is stored inside a new array of groups in the Field hierarchy called "time_node_data." These groups are used to extend the base data schema, Node_Data Node_Data_Byte, Node_Data_Short, Node_Data_Int, and Node_Data_Float, to support multistep node data: Time_Node_Data, Time_Node_Data_Byte, Time_Node_Data_Short, Time_Node_Data_Int, and Time_Node_Data_Float.

The time dependent node data groups, extend their base objects in the following ways:

Similarly, time dependent cell data is stored inside a new array of groups in the Cell_Set hierarchy called "time_cell_data." and included in the new Data Schema groups, Time_Cell_Data, Time_Cell_Data_Poly, Time_Cell_Data_Set, and Time_Cell_Data_Set_Poly.

The time dependent cell data groups, extend their base objects in the following ways:

Visualization Concepts

2 The Field:The AVS/Express Data Model

2 The Field:
The AVS/Express Data Model