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

[Mike Jackson]

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