Pipeline IDs: Difference between revisions
DaveDemarle (talk | contribs) |
|||
Line 6: | Line 6: | ||
IDs are unique data types - they may not be the same as a typical DatArray. | IDs are unique data types - they may not be the same as a typical DatArray. | ||
* Data objects such as vtkDataArray must be able to use IDs as accessors into their arrays. | * Data objects such as vtkDataArray must be able to use IDs as accessors into their arrays. | ||
* IDs | |||
* ID arrays should never be interpolated, unless done with nearest neighbor interpolation. | |||
IDs are not parts of a mathematical "Field" the way, say, Temperatures are. | |||
Addition, multiplication and interpolation on IDs have no meaning. It just | |||
so happens that IDs can be conviently stored in integers and moved around with | |||
the rest of the arrays in a vtkField. | |||
* Copying IDs from input to output should always preserve meaning. | |||
In general, algorithms that do not modify topology can pass IDs through because | |||
the name of each cell and point is mappable across the filter. Algorithms that | |||
do modify topology, increasing the number of cells for instance, must do | |||
something more intelligent to preserve the meaning of the IDs. There will be | |||
exceptions to either rule, subsetting for instance. | |||
Copying can be guided by the vtk class hierarchy and array methods but in | |||
general, since the filter programmer has write access to the arrays, the | |||
responsibility for obeying the policy lies with the programmer. | |||
* IDs must be able to be 'hidden', so that they won't clutter up the 'normal' array name space. Whenever possible, users should be able to ignore this data. | * IDs must be able to be 'hidden', so that they won't clutter up the 'normal' array name space. Whenever possible, users should be able to ignore this data. | ||
* IDs must be able to be 'shown', if the user wants to color the data using these. | * IDs must be able to be 'shown', if the user wants to color the data using these. | ||
===Pedigree ID=== | ===Pedigree ID=== |
Latest revision as of 20:15, 23 February 2006
Overview
Currently, there is no native support for unique identifiers in vtk/ParaView. There are many issues that relate to this.
Proposal
IDs are unique data types - they may not be the same as a typical DatArray.
- Data objects such as vtkDataArray must be able to use IDs as accessors into their arrays.
- ID arrays should never be interpolated, unless done with nearest neighbor interpolation.
IDs are not parts of a mathematical "Field" the way, say, Temperatures are. Addition, multiplication and interpolation on IDs have no meaning. It just so happens that IDs can be conviently stored in integers and moved around with the rest of the arrays in a vtkField.
- Copying IDs from input to output should always preserve meaning.
In general, algorithms that do not modify topology can pass IDs through because the name of each cell and point is mappable across the filter. Algorithms that do modify topology, increasing the number of cells for instance, must do something more intelligent to preserve the meaning of the IDs. There will be exceptions to either rule, subsetting for instance.
Copying can be guided by the vtk class hierarchy and array methods but in general, since the filter programmer has write access to the arrays, the responsibility for obeying the policy lies with the programmer.
- IDs must be able to be 'hidden', so that they won't clutter up the 'normal' array name space. Whenever possible, users should be able to ignore this data.
- IDs must be able to be 'shown', if the user wants to color the data using these.
Pedigree ID
A pedigree ID is defined as the ID which relates input objects to output objects. It is used to follow the 'pedigree' of an object. This ID is applied by a filter, in a way defined by its operation. Two examples illustrate its use.
Constraints
- A Pedigree ID is copied from parent to child. Any filter that creates cells that have a parent/child relationship should copy the Pedigree ID appropriately.
- A Pedigree ID may not be arbitrarily overwritten by any filter in the pipeline.
- Certain operations, such as interpolation, should never be performed on a Pedigree ID.
Unique IDs
A Unique ID is an identifier for points or cells which uniquely defines each in a parallel data set. Any time two points or cells have the same Unique ID, they are considered to be the same. At present, the D3 filter is the only filter that uses this capability, and we are looking into whether or not the general capability is needed, or if this should be implemented only inside the D3 filter.
Constraints
- The set of Unique IDs needn't be contiguous.
- There is no relationship between a filter's input Unique ID set and its output Unique ID set.
- If a filter divides or creates cells, then the cell Unique ID array must be rebuilt.
- If a filter interpolates or creates points, then the point Unique ID array must be rebuilt.
- The Unique ID data need not exist, and does not have to be passed along by filters. Not passing this data should be the default behavior.
Other IDs
If the Pedigree ID and the Unique ID are not sufficient, a filter may create its own named ID. It may not overwrite other ID types. It's not clear if this is a requirement, but we should consider it in the design.