[Paraview] RequestData Being Called Multiple Times [PV3.1.0]
Berk Geveci
berk.geveci at kitware.com
Wed Jul 18 10:31:56 EDT 2007
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