Pipeline IDs: Difference between revisions

From ParaQ Wiki
Jump to navigationJump to search
 
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 must be copied from input to output. It is unclear at this point if this requirement should be enforced by superclasses, or if it is a policy, and therefore responsibility lies with the filter programmer.
 
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.