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

Mike Jackson imikejackson at gmail.com
Wed Jul 18 10:33:12 EDT 2007


No. There might be a possibility in the future.. This reader really  
lends itself to parallism. The filtering at the end of the reader is  
one of those "embarrassingly" parallel filters.


-- 
Mike Jackson   Senior Research Engineer
Innovative Management & Technology Services


On Jul 18, 2007, at 10:31 AM, Berk Geveci wrote:

> Are you running in parallel?
>
> On 7/18/07, Mike Jackson <imikejackson at gmail.com> wrote:
>> Then I do not understand what I should be doing. What I put "works"
>> but maybe not in the "right" way.
>>
>> In my RequestInformatio(...) I have:
>>
>>    outInfo->Set( vtkDataObject::ORIGIN(), DataOrigin, 3 );
>>    outInfo->Set( vtkDataObject::SPACING(), DataSpacing, 3 );
>>    outInfo->Set( vtkStreamingDemandDrivenPipeline::WHOLE_EXTENT(),
>> DataExtent, 6 );
>>    outInfo->Set( vtkStreamingDemandDrivenPipeline::UPDATE_EXTENT(),
>> DataExtent, 6 );
>>
>> Then in my RequestData(...) I have:
>>
>> vtkImageData *output = vtkImageData::SafeDownCast(outInfo->Get
>> (vtkDataObject::DATA_OBJECT()));
>>    output->SetScalarType(VTK_TYPE_FLOAT32);
>>    output->SetSpacing( 1.0, 1.0, 1.0 );
>>    output->SetOrigin( 0.0, 0.0, 0.0 );
>>    output->SetDimensions( xDim, yDim, zDim );
>>    output->SetNumberOfScalarComponents( 1 );
>>    output->AllocateScalars();
>> ... Load the data from the file into the 'output' object
>>    return 1;
>>
>> I see other readers doing it this way, or so it seems, it was late
>> last night. So my question is:
>>
>> How _should_ I be doing this? I am not sure there is a time where I
>> would only update part of the volume. I always want to read all the
>> volume from the file. Maybe I am just missing something.
>>
>>
>> --
>> Mike Jackson   Senior Research Engineer
>> Innovative Management & Technology Services
>>
>>
>> On Jul 18, 2007, at 10:04 AM, Berk Geveci wrote:
>>
>> > 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
>>
>>
>
>
> -- 
> Berk Geveci
> Kitware Inc.
> 28 Corporate Drive
> Clifton Park, NY, 12065



More information about the ParaView mailing list