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

Wed Jul 18 10:04:37 EDT 2007

You should not be setting UPDATE_EXTENT. You should let the pipeline
set it and respond to it appropriately in RequestData().

-berk

On 7/18/07, Mike Jackson <imikejackson at gmail.com> wrote:
> THANKS.. That was the problem.. mostly.. I included the following:
>
>    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-1;
>    this->DataExtent[3] = yDim-1;
>    this->DataExtent[5] = zDim-1;
>    outInfo->Set( vtkStreamingDemandDrivenPipeline::WHOLE_EXTENT(),
> DataExtent, 6 );
>    outInfo->Set( vtkStreamingDemandDrivenPipeline::UPDATE_EXTENT(),
> DataExtent, 6 );
>
> in the RequestInformation and now RequestData only gets called once.
> There was also a bug in my last code where I was not quite
> calculating the DataExtent correctly. I _had_ :
> t this->DataExtent[1] = xDim;
>
> which should have been:
>
> this->DataExtent[1] = xDim-1;
>
> Thanks to all those who replied with Ideas and ultimately the
> solution. I'll write this little gem in my notes so next time I have
> a better idea of what all is needed in a Reader based on
> vtkImageAlgorithm.
>
> --
> Mike Jackson   Senior Research Engineer
> Innovative Management & Technology Services
>
>
> On Jul 18, 2007, at 9:19 AM, Berk Geveci wrote:
>
> > 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
>
> _______________________________________________
> 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