IBM Visualization Data Explorer Programmer's Reference

14.4 Growing and Shrinking Partitioned Data

The routines listed at the end of this section are necessary for processing Composite Fields.

Some modules (e.g., filters) require information from the neighborhood of each point. Since partitioning divides data into spatially disjoint subsets for independent processing, a neighborhood may be divided among different partitions: for example, a filter kernel may overlap the boundary between two partitions. In such cases, processing one partition requires information that resides in the other.

In order to facilitate such information sharing, Data Explorer includes routines that support temporarily overlapping partitions. DXGrow() modifies its input Field and adds to each partition information from the partition's neighbor(s).

Because DXGrow() modifies its input, the calling routine must use DXCopy() to copy the input structure if that structure is not to be modified. After this boundary information has been accrued, the processing of the partition may be handled independently since all information required to produce correct results for the original partition is available in it. For example, in the case of filtering, boundary information is added so that wherever a filter kernel is placed in the original partition, the kernel does not extend outside the grown partition, producing correct results in the original partition. After processing the Field produced by DXGrow(), DXShrink() must be called to shrink any components that have not been shrunk by the caller, and to remove extra references to the original components that were put in the Field by DXGrow().

When DXGrow() is called, the depth of an overlap region is specified by specifying the number of rings to be accrued. An element is said to be in the kth ring if it has at least one vertex in the kth ring. A vertex is in the 0th ring if it exists both in the partition and the neighbor, and is in the kth ring if it is not in a lower ring and an element in ring k-1 is incident upon it. Most frequently, such modules produce results for each vertex on the basis of the elements incident on that vertex; this is achieved by requesting that DXGrow() include 1 ring: those elements from neighboring partitions that are incident on vertices that exist in both partitions.

The treatment of the exterior boundary of regular grid data is specified by a parameter to DXGrow(). You may specify that the Field not be expanded beyond its boundary (i.e., that the exterior partitions not be expanded except on the sides that border other partitions). Alternatively you may specify that the Field be expanded beyond its original boundaries, with the new data being filled in one of three ways: with a constant value; with the replicated value from the nearest edge point in the original Field; or with nothing, only reserving space for the new data but leaving its contents undefined.

While it is necessary that the footprint of a filter kernel, placed anywhere in the original partition, not extend past the grown partition boundary, it is probably not necessary to apply the filter in the boundary regions accrued from neighbors; these regions are properly handled during the processing of the neighboring partition. Data Explorer also includes routines that query the original number of positions and connections (in the case of irregular grids) or the offset relative to the grown partition and size of the original partition.

Frequently, modules do not require all components of a Field that are dependent on the positions to be grown. To avoid accruing information that will not be required during processing, DXGrow() requires the calling application to specify which components, in addition to positions and connections, will be required.

Modules using DXGrow() have the option of producing results corresponding to the positions of the larger grown Field or, more efficiently, producing results corresponding only to positions of the original smaller Field. Even though the former method is less efficient, involving more data movement and perhaps more calculation, it is sometimes more convenient. Therefore, the DXShrink() function is provided to shrink all components that depend on or reference positions or connections back to their original size. If the user has already shrunk the positions, DXShrink() will leave them unmodified. In any case, the DXShrink() function must be called after operating on a grown Field in order to remove references to the "original" components that were placed in the Field by DXGrow() for later use by DXShrink().

For each component specified in the component list passed to DXGrow(), a component named "original componentname" is created. DXShrink() will rename each of these to its original name. Therefore, for components you have modified (e.g., data), you should remove the corresponding original component ("original data" in this example) before calling DXShrink().

Both DXGrow() and DXShrink() operate in parallel on Composite Fields. For that reason, DXGrow() must be called prior to any subtasking invoked explicitly by the calling application; DXShrink() must be called after any such subtasking has been completed.

#define GROW_NONE      NULL
#define GROW_REPLICATE ((Pointer)1)
#define GROW_NOFILL    ((Pointer)2)

[Data Explorer Home Page | Contact Data Explorer | Same document on Data Explorer Home Page ]