<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
OK. I take it all back. It totally stuffs everything up because now the
Update Extent gets set to the Whole Extent all over the place<br>
<br>
Suggestions?<br>
<br>
JB<br>
<br>
<blockquote cite="mid:47A6FDC9.7080208@cscs.ch" type="cite">
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
The issue is caused by a check in vtkTrivial Producer<br>
<br>
I've added an extra check in red here. I doubt this will affect
anything and I'll run the tests to make sure. <br>
<br>
else if (<font color="#cc0000">!outputInfo->Has(vtkStreamingDemandDrivenPipeline::WHOLE_EXTENT())</font>
&&<br>
dataInfo->Get(vtkDataObject::DATA_EXTENT_TYPE()) ==
VTK_3D_EXTENT)<br>
{<br>
// The whole extent is just the extent because the output has no<br>
// real source to change its data.<br>
int extent[6];<br>
dataInfo->Get(vtkDataObject::DATA_EXTENT(), extent);<br>
outputInfo->Set(vtkStreamingDemandDrivenPipeline::WHOLE_EXTENT(),<br>
extent, 6);<br>
}<br>
<br>
Anyone care to comment?<br>
<br>
JB<br>
<br>
<br>
<blockquote cite="mid:47A6DDA6.6070801@cscs.ch" type="cite">Utkarsh <br>
<br>
I've got one use case scenario that fits the MultiPiece dataset.... <br>
<br>
I have 8 pieces of a volume which are placed into a multiblock dataset.
Pieces are 0-11, 12-23 along each eaxis. <br>
<br>
When I create the data, I put WholeExtent 0-23 and Extent 0-11 or 12-23
as required and all is well. Then I pass the data into another filter
and <br>
<br>
reader -> GetDataSet(0,i)->GetWholeExtent(...) returns 0-23,
0,23, 0-23 <br>
filter->SetInput(output...) (executive is composite) <br>
filter->Update() <br>
reader -> GetDataSet(0,i)->GetWholeExtent(...) returns 0-11,
0,11, 0,11 or 12-23, 23-23, 12-23 ie WholeExtent=Extent <br>
<br>
The whole extent is always being reset to the actual extents. This is
bad and I think it is a bug (- I lose precious information that I need
to use when piecing the data back together later). But if there is a
reason for it (and I'm trying to chase it down as I write), then I can
see a case for handling a piece dataset differently. <br>
<br>
I say no more until I've investigated further. <br>
<br>
JB <br>
<br>
<br>
<blockquote type="cite">John, <br>
<br>
I am done with most of the coding, so now basically waiting for
feedback and the dashboard to clean up before committing the changes.
Just to clarify, the vtkMultiPieceDataSet part won't get implemented in
this pass. There's still no consensus here on the necessity of it
given that the same can be achieved by vtkMultiBlockDataSet or whether
it should be a new class or simply an ivar (or some other
qualification) on vtkMultiBlockDataSet. <br>
<br>
Utkarsh <br>
<br>
John Biddiscombe wrote: <br>
<blockquote type="cite">Utkarsh <br>
<br>
I'm very keen to try out the MultiPiece dataset. I think it will make a
significant difference to the development of several readers for data
that has been dumped into files - one per processor. Do you have a
likely timeframe in which you'll be commiting things? <br>
<br>
JB <br>
<br>
<blockquote type="cite">Folks, <br>
<br>
Composite data pipeline is undergoing a redesign to overcome some of
its current limitations. Details of the issues, the new design and the
implementation are available at: <br>
<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://www.vtk.org/Wiki/VTK/Composite_Data_Redesign">http://www.vtk.org/Wiki/VTK/Composite_Data_Redesign</a>
<br>
<br>
To summarize: vtkCompositeDataSet has been modified to support a full
tree datastructure instead of a table of tables approach used by the
previous implementation. It is possible to traverse the tree using
iterators. The iterators are more powerful than before making it
possible to not only access the datasets, but also change them.
vtkHierarchicalDataSet and vtkMultiGroupDataSet have been deprecated.
The only concrete composite datasets available are
vtkMultiBlockDataSet, vtkHierarchicalBoxDataSet and vtkTemporalDataSet.
<br>
<br>
The new code is not available in CVS yet. I'll wait a few days for
people to respond before committing it. <br>
<br>
Utkarsh <br>
_______________________________________________ <br>
Paraview-developers mailing list <br>
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:Paraview-developers@paraview.org">Paraview-developers@paraview.org</a>
<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://public.kitware.com/mailman/listinfo/paraview-developers">http://public.kitware.com/mailman/listinfo/paraview-developers</a>
<br>
</blockquote>
<br>
<br>
</blockquote>
</blockquote>
<br>
<br>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="78">--
John Biddiscombe, email:biddisco @ cscs.ch
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://www.cscs.ch/about/BJohn.php">http://www.cscs.ch/about/BJohn.php</a>
CSCS, Swiss National Supercomputing Centre | Tel: +41 (91) 610.82.07
Via Cantonale, 6928 Manno, Switzerland | Fax: +41 (91) 610.82.82</pre>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
Paraview-developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Paraview-developers@paraview.org">Paraview-developers@paraview.org</a>
<a class="moz-txt-link-freetext" href="http://public.kitware.com/mailman/listinfo/paraview-developers">http://public.kitware.com/mailman/listinfo/paraview-developers</a>
</pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="78">--
John Biddiscombe, email:biddisco @ cscs.ch
<a class="moz-txt-link-freetext" href="http://www.cscs.ch/about/BJohn.php">http://www.cscs.ch/about/BJohn.php</a>
CSCS, Swiss National Supercomputing Centre | Tel: +41 (91) 610.82.07
Via Cantonale, 6928 Manno, Switzerland | Fax: +41 (91) 610.82.82</pre>
</body>
</html>