[Paraview] RequestData Being Called Multiple Times [PV3.1.0]

[Berk Geveci]

Multiple execution problems like this usually occur due to
inconsistency between what the pipeline requests and what the
algorithm produces. Can you verify that your reader is producing the
extent requested (with UPDATE_EXTENT)? The extent of the data the
reader produces has to match UPDATE_EXTENT().

-berk

On 7/17/07, Mike Jackson <imikejackson at gmail.com> wrote:
> After looking at this all day today, I the big difference is:
>
> If I include the following code:
>
>    outInfo->Set( vtkDataObject::ORIGIN(), DataOrigin, 3 );
>    outInfo->Set( vtkDataObject::SPACING(), DataSpacing, 3 );
>
>    this->DataExtent[0] = this->DataExtent[2] = this->DataExtent[4] = 0;
>    this->DataExtent[1] = xDim;
>    this->DataExtent[3] = yDim;
>    this->DataExtent[5] = zDim;
>    outInfo->Set( vtkStreamingDemandDrivenPipeline::WHOLE_EXTENT(),
> DataExtent, 6 );
>
> Then after each call to RequestData, a call to SetAbortExecute (0) is
> called which I think is causing an update to occur. If I leave the
> above code out, then only GetAbortExecute() is called, which is fine
> as it does not monkey with the ModifiedTime.
>
> Now I would be more than happy to leave out the above code, but doing
> so leaves the resulting vtkImageData object not quite "right", ie, It
> will show an outline in paraview, but nothing else. Maybe someone can
> fill me in on what is going on.
>
> I am thinking of maybe trying to inherit from vtkStructuredGrid
> instead. Our data is just a regular array of Voxels with some extra
> scalar and vector attributes on them.
>
> I do not have this problem with a vtkPolyDataAlgorithm..
>
>
> --
> Mike Jackson   Senior Research Engineer
> Innovative Management & Technology Services
>
>
> On Jul 17, 2007, at 12:58 PM, Moreland, Kenneth wrote:
>
> > Another thought.  Are you calling Modified (either directly or
> > indirectly) in RequestData?  If the modified flag gets called, VTK
> > will
> > assume that the data is out of date and run RequestData again whenever
> > possible.  Check the value of the MTime ivar at the beginning and the
> > end of RequestData.  It should be the same.
> >
> > -Ken
> >
> >> -----Original Message-----
> >> From: paraview-bounces+kmorel=sandia.gov at paraview.org
> > [mailto:paraview-
> >> bounces+kmorel=sandia.gov at paraview.org] On Behalf Of Mike Jackson
> >> Sent: Tuesday, July 17, 2007 10:45 AM
> >> To: eschenbe at psc.edu
> >> Cc: ParaView
> >> Subject: Re: [Paraview] RequestData Being Called Multiple Times
> > [PV3.1.0]
> >>
> >> I finally got a debugger working and setting a breakpoint at the top
> >> of RequestData is interesting to say the least. The stack is anywhere
> >> from 69 to 72 deep at that point. Copying the stack from each time
> >> the break point is hit and pasting into text files, the running a
> >> diff against two of the files shows the the differences are about the
> >> 39 to 42 depth. All this is way beyond me at this point. I can send
> >> the stack traces if anyone wants to look through them.. ;-)
> >>
> >>      Maybe I will try and compile this against 2.6.x and see if the
> >> problem persists. I have written another reader that inherits from
> >> PolyDataAlgorithm and I don't have this sort of trouble. I am sure it
> >> is something stupid that I am doing. I am looking at the ImageReader2
> >> class to get an idea of what I _should_ be doing at this point.
> >>
> >>
> >> --
> >> Mike Jackson   Senior Research Engineer
> >> Innovative Management & Technology Services
> >>
> >>
> >> On Jul 17, 2007, at 12:21 PM, Kent Eschenberg wrote:
> >>
> >>> Mike Jackson wrote:
> >>>> That does not seem to be it.. Although good idea. Any other
> >>> thoughts?
> >>>
> >>>> On Jul 17, 2007, at 11:59 AM, Kent Eschenberg wrote:
> >>>>> I've seen that when RequestData returns a value that signals an
> >>> error.
> >>>
> >>> Only a crude shot in the dark: set a breakpoint at the start of
> >>> RequestData and see if the traceback suggests why the call was
> >>> made. I've written several readers for 2.6.1 and haven't seen the
> >>> problem you report except when the reader's return value indicated
> >>> an error.
> >>>
> >>> Kent
> >>> Pittsburgh Supercomputing Center
> >>
> >> _______________________________________________
> >> ParaView mailing list
> >> ParaView at paraview.org
> >> http://www.paraview.org/mailman/listinfo/paraview
> >
> >
>
> _______________________________________________
> ParaView mailing list
> ParaView at paraview.org
> http://www.paraview.org/mailman/listinfo/paraview
>


-- 
 Berk Geveci
 Kitware Inc.
 28 Corporate Drive
 Clifton Park, NY, 12065