[Paraview] What part of the pipeline is producing the request for UPDATE_EXTENT?

John Biddiscombe biddisco at cscs.ch
Thu Feb 14 02:46:19 EST 2008 

Mike,

> Any idea what produces those types of errors? I have been testing the 
> code pretty heavily this afternoon and all _seems_ to be working 
> correctly....
If it is working, then there's no need for me to scare you any more...but...

In the old days the chain of events used to go like this...
You have some data on disk that is {0,3N}, {0,...} big along each axis, 
but you load a VOI that is {0,N} along each axis, all is well, you set 
the whole extent to {0,N} and we are happy. Then the user changes the 
VOI to {N,2N} and the update extent gets set to that - but the whole 
extent is smaller and has not been updated - a call to Request 
Information was needed between you changing the VOI and the update 
extent being set. I suspect this extra call now happens so the WholeExt 
is set after you changed VOI and the UpExt is now inside it.

anyway...if it ain't broke..don't fix it. I have trouble of my own 
convincing this Xdmf reader to load pieces of imagedata in parallel 
properly and set the extents and bounds right. It is loading the pieces 
as expected, but the boxes on screen are only part of the data.....

JB

>
> I can go from a VOI of 0, 500, 0, 500, 100, 102 -> 2000, 3000, 1800, 
> 2500, 106, 108 and there didn't seem to be problem?
>
> Mike
>
> On Feb 13, 2008, at 3:47 PM, John Biddiscombe wrote:
>
>> I'd like to be a fly on the wall in your office when you start 
>> getting the infamous "Update extent is not within the Whole Extent" 
>> messages when you change your VOI!
>>
>> JB
>>
>>> Thank you so very much. I was able to implement what you wrote and 
>>> now my reader is behaving much better in ParaView. I have put in 
>>> some additional checks to see if either the input file or the VOI 
>>> has changed to cut down on reading information from the file when it 
>>> hasn't changed.
>>>
>>> Thanks for everyone sticking with me
>>> Mike Jackson
>>>
>>> On Feb 13, 2008, at 12:48 PM, Moreland, Kenneth wrote:
>>>
>>>> In the example you give, you should just report 500, 1500, 200, 
>>>> 1800, 100, 105 in WHOLE_EXTENT and respond to whatever 
>>>> UPDATE_EXTENT the pipeline asks you for.  If you are in serial 
>>>> mode, UPDATE_EXTENT should be set to WHOLE_EXTENT.  On a parallel 
>>>> server, ParaView will automatically break up the WHOLE_EXTENT and 
>>>> set the UPDATE_EXTENT on each process to a different piece.  In 
>>>> either case, just respond to the UPDATE_EXTENT that the pipeline 
>>>> gives you and that should work.
>>>>
>>>> How is this not working?  Are we talking about the multiple calls 
>>>> to RequestData again?  Could it be that you have set the wrong 
>>>> extents information on the output data?
>>>>
>>>> -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: Wednesday, February 13, 2008 10:23 AM
>>>>> To: ParaView
>>>>> Subject: Re: [Paraview] What part of the pipeline is producing the 
>>>>> request
>>>>> for UPDATE_EXTENT?
>>>>>
>>>>> I understand. Now. my problem. In RequestInformation I read part of
>>>>> my file to get what I am assuming should be the "WHOLE_EXTENT", which
>>>>> is 7334 x 8448 x 200 as a uint8 vtkImageData object. This is too
>>>>> large to fit into memory the machines that this will be run on. I
>>>>> placed some auto-generated gui widgets in ParaView for the customer
>>>>> to select a VOI. I have used the normal vtk macros for the set/get
>>>>> methods for VOI.
>>>>>
>>>>> So say the customer is only interested in a VOI of 500, 1500, 200,
>>>>> 1800, 100, 105. Could you lay out what calls should be made in each
>>>>> of the RequestInformation and RequestData methods? (just the major
>>>>> things we have been talking about, I can fill in the rest). I have
>>>>> tried lots of different configurations and the only ones that seem to
>>>>> work are the ones that are NOT recommended to do.
>>>>>
>>>>> If you want the entire vtkH5RoboMetReader.h/cpp, I can send that
>>>>> along also.
>>>>>
>>>>> Thanks
>>>>> Mike.
>>>>>
>>>>>
>>>>> On Feb 13, 2008, at 12:10 PM, Moreland, Kenneth wrote:
>>>>>
>>>>>> In the call to loadDataFromMXAFile, you should be using the value
>>>>>> in UPDATE_EXTENT, not VOI.  To review, WHOLE_EXTENT is what the
>>>>>> reader reports to the downstream components what data is available
>>>>>> (and reporting VOI is an easy way to limit the data to what the
>>>>>> user wants).  UPDATE_EXTENT is the part of the data that the
>>>>>> downstream components want.  If you return with data that does not
>>>>>> match up to UPDATE_EXTENT, the pipeline might execute again trying
>>>>>> to get the range of data it asked for.
>>>>>>
>>>>>> -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: Wednesday, February 13, 2008 9:48 AM
>>>>>>> To: ParaView
>>>>>>> Subject: Re: [Paraview] What part of the pipeline is producing the
>>>>>>> request
>>>>>>> for UPDATE_EXTENT?
>>>>>>>
>>>>>>> Ok, so now I have
>>>>>>> RequestInformation()
>>>>>>> {
>>>>>>> ...
>>>>>>> outInfo->Set( vtkStreamingDemandDrivenPipeline::WHOLE_EXTENT(), 
>>>>>>> this-
>>>>>>>> VOI, 6 );
>>>>>>> ...
>>>>>>> }
>>>>>>>
>>>>>>> and RequestData() I load the data into a newly created vtkImageData
>>>>>>> object, then shallow copy into the
>>>>>>> actual output data object:
>>>>>>>
>>>>>>> vtkInformation* outInfo = outputVector->GetInformationObject(0);
>>>>>>> vtkImageData* output = vtkImageData::SafeDownCast(outInfo->Get
>>>>>>> (vtkDataObject::DATA_OBJECT()));
>>>>>>> vtkTypeInt32 error = 1;
>>>>>>> vtkSmartPointer<vtkImageData> imageData =
>>>>>>> vtkSmartPointer<vtkImageData>::New();
>>>>>>> error = loadDataFromMXAFile(outInfo, imageData, this->VOI);
>>>>>>> output->ShallowCopy(imageData);
>>>>>>>
>>>>>>> In paraview from CVS this causes multiple executions of the 
>>>>>>> pipeline.
>>>>>>> Before, where I thought I had "fixed" the issue I was calling:
>>>>>>>
>>>>>>> outInfo->Set( vtkStreamingDemandDrivenPipeline::WHOLE_EXTENT(), 
>>>>>>> this-
>>>>>>>> VOI, 6 );
>>>>>>>
>>>>>>> in RequestData(). Berk said that wasn't a good idea so I removed 
>>>>>>> it.
>>>>>>> So now I am back to square 1 again.
>>>>>>>
>>>>>>> Thanks
>>>>>>> Mike
>>>>>>>
>>>>>>> On Feb 13, 2008, at 10:17 AM, Kent Eschenberg wrote:
>>>>>>>
>>>>>>>> Indeed, each of the my routines to set the VOI bounds (one each 
>>>>>>>> for
>>>>>>>> the min/max in X/Y/Z) calls Modified().
>>>>>>>>
>>>>>>>> During development I had temporary print statements everywhere and
>>>>>>>> as I remember it these routines to set the VOI were called both
>>>>>>>> before and after RequestInformation.
>>>>>>>>
>>>>>>>> Kent
>>>>>>>> Pittsburgh Supercomputing Center
>>>>>>>>
>>>>>>>> Moreland, Kenneth wrote:
>>>>>>>>> I belive it is supposed to work that your SetVOI() method should
>>>>>>>>> call modified, which will in turn cause the pipeline to call
>>>>>>>>> RequestInformation() on the next update.  Make sure that SetVOI()
>>>>>>>>> is actually calling Modified().
>>>>>>>>> -Ken
>>>>>>>>> On 2/12/08 9:26 PM, "Mike Jackson" <imikejackson at gmail.com> 
>>>>>>>>> wrote:
>>>>>>>>>     Pretty sure that was where we were going to end up BUT as far
>>>>>>>>> as I
>>>>>>>>>     can tell, the order of execution is :
>>>>>>>>>     RequestInformation()
>>>>>>>>>     SetVOI() // From the GUI in ParaView
>>>>>>>>>     RequestData();
>>>>>>>>>     So we never really get a chance to get the VOI until
>>>>>>>>> RequestData
>>>>>>>>>     fires.. Is that what you have seen?
>>>>>>>>>     Mike
>>>>>>>>>     On Feb 12, 2008, at 11:21 PM, Kent Eschenberg wrote:
>>>>>>>>>>  Mike,
>>>>>>>>>>
>>>>>>>>>>  I accomplished what you want with one of our custom
>>>>>>>>> readers. In my
>>>>>>>>>>  opinion the documentation for RequestInformation, RequestData,
>>>>>>>>>>  extents, etc. is so poor that it is useless.
>>>>>>>>>>
>>>>>>>>>>  At RequestInformation I read enough of the input to get the
>>>>>>>>> overall
>>>>>>>>>>  input array size; apply the user-selected VOI; and return the
>>>>>>>>>>  desired subset as the whole extent. At RequestData I read
>>>>>>>>> the rest.
>>>>>>>>>>  I just don't bother letting VTK/ParaView manage the
>>>>>>>>> selection of
>>>>>>>>>>  the VOI. This has worked for 2.6.1 through 3.2.1.
>>>>>>>>>>
>>>>>>>>>>  Kent
>>>>>>>>>>  Pittsburgh Supercomputing Center
>>>>>>>>>>
>>>>>>>>>>  Mike Jackson wrote:
>>>>>>>>>>> I can do that but I don't think it will work.
>>>>>>>>>>> In paraview, I have managed to set an auto-generated UI
>>>>>>>>> for the
>>>>>>>>>>> VOI. Now, the user opens our file, RequestInformation is
>>>>>>>>> run (I
>>>>>>>>>>> can put some sane defaults for the VOI) and things are ok
>>>>>>>>> so far.
>>>>>>>>>>> Now the user clicks "Apply" and then SetVOI is called with
>>>>>>>>> the
>>>>>>>>>>> values from the GUI and then RequestData() is called after
>>>>>>>>> that.
>>>>>>>>>>> So where do I update WHOLE_EXTENT? Or just take the values
>>>>>>>>> from
>>>>>>>>>>> the VOI, create a vtkImageObject from that, and then just
>>>>>>>>>>> ShallowCopy to the output object?
>>>>>>>>>>> I'm a bit confused at this point. If our case is NOT a
>>>>>>>>> standard
>>>>>>>>>>> use case for the pipeline than I guess I can look more
>>>>>>>>> seriously
>>>>>>>>>>> into developing a full blown Plugin for our data file.
>>>>>>>>>>> Mike
>>>>>>>
>>> _______________________________________________
>>> \
> _______________________________________________
> ParaView mailing list
> ParaView at paraview.org
> http://www.paraview.org/mailman/listinfo/paraview


-- 
John Biddiscombe,                            email:biddisco @ cscs.ch
http://www.cscs.ch/about/BJohn.php
CSCS, Swiss National Supercomputing Centre  | Tel:  +41 (91) 610.82.07
Via Cantonale, 6928 Manno, Switzerland      | Fax:  +41 (91) 610.82.82

More information about the ParaView mailing list