Talk:Composite Redesign: Difference between revisions
m (A couple of "right ons" and a "whoa there.") |
mNo edit summary |
||
| (One intermediate revision by the same user not shown) | |||
| Line 1: | Line 1: | ||
Berk, I like the idea of eliminating vtkMultiGroupDataSet and I agree that it's confusing to assume first-level (or second-level in the case of vtkTemporalDataSet) sub-blocks are chunks of data from different compute nodes with ostensibly the same structure. I share your uncertainty about vtkMultiPieceDataSet... it seems like a lot of work. One alternative might be to use vtkInformation keys to mark blocks that share structure and provide some utility routines in the base class to help with ghost levels, etc. | Berk, I like the idea of eliminating vtkMultiGroupDataSet and I agree that it's confusing to assume first-level (or second-level in the case of vtkTemporalDataSet) sub-blocks are chunks of data from different compute nodes with ostensibly the same structure. I share your uncertainty about vtkMultiPieceDataSet... it seems like a lot of work. One alternative might be to use vtkInformation keys to mark blocks that share structure and provide some utility routines in the base class to help with ghost levels, etc. | ||
My other concern for composite datasets is how point/cell/field data arrays defined over sub-blocks (or sub-sub blocks, etc.) are handled in the pipeline. If you end up reworking the executive, perhaps that would be a good time to fiddle with how | |||
* a downstream filter requests a list of available (not neccessarily present) arrays on multiblock data in the RequestInformation phase (another way to phrase this: how does a source advertise arrays on multiblock datasets?). | |||
* a downstream filter requests a set of arrays on a per-block basis during the RequestData phase. | |||
--[[User:Dcthomp|Dcthomp]] 22:45, 25 November 2007 (EST) | |||
Latest revision as of 23:03, 25 November 2007
Berk, I like the idea of eliminating vtkMultiGroupDataSet and I agree that it's confusing to assume first-level (or second-level in the case of vtkTemporalDataSet) sub-blocks are chunks of data from different compute nodes with ostensibly the same structure. I share your uncertainty about vtkMultiPieceDataSet... it seems like a lot of work. One alternative might be to use vtkInformation keys to mark blocks that share structure and provide some utility routines in the base class to help with ghost levels, etc.
My other concern for composite datasets is how point/cell/field data arrays defined over sub-blocks (or sub-sub blocks, etc.) are handled in the pipeline. If you end up reworking the executive, perhaps that would be a good time to fiddle with how
- a downstream filter requests a list of available (not neccessarily present) arrays on multiblock data in the RequestInformation phase (another way to phrase this: how does a source advertise arrays on multiblock datasets?).
- a downstream filter requests a set of arrays on a per-block basis during the RequestData phase.
--Dcthomp 22:45, 25 November 2007 (EST)
