[Paraview] RequestData Being Called Multiple Times [PV3.1.0]
Mike Jackson
imikejackson at gmail.com
Wed Jul 18 10:20:21 EDT 2007
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
More information about the ParaView
mailing list