[vtk-developers] RequestUpdateExtent not called after modified

[Berk Geveci]

It is hard to guess whether the problem is the same without seeing code.
However, this issue was fixed in VTK master so you may want to update and
see for yourself. I am including below the documentation explaining the
change (also available in Documentation/Doxygen/ChangesVTK-7-1.md).

However, if RequestInformation() executes and RequestData() executes, it is
impossible for RequestUpdateExtent() not to execute. There is no code path
for this. So something is fishy.

Best,
-berk


Pipeline Update Methods
-----------------------

The following methods were deprecated in VTK 7.1:

### vtkAlgorithm:

    int SetUpdateExtentToWholeExtent(int port);
    int SetUpdateExtentToWholeExtent();
    void SetUpdateExtent(int port,
                         int piece,int numPieces, int ghostLevel);
    void SetUpdateExtent(
      int piece,int numPieces, int ghostLevel);
    void SetUpdateExtent(int port, int extent[6]);
    void SetUpdateExtent(int extent[6]);

### vtkStreamingDemandDrivenPipeline:

    int SetUpdateExtentToWholeExtent(int port);
    static int SetUpdateExtentToWholeExtent(vtkInformation *);
    int SetUpdateExtent(int port, int extent[6]);
    int SetUpdateExtent(int port, int x0, int x1, int y0, int y1, int z0,
int z1);
    static int SetUpdateExtent(vtkInformation *, int extent[6]);
    int SetUpdateExtent(int port,
                        int piece, int numPieces, int ghostLevel);
    static int SetUpdateExtent(vtkInformation *,
                               int piece, int numPieces, int ghostLevel);
    static int SetUpdatePiece(vtkInformation *, int piece);
    static int SetUpdateNumberOfPieces(vtkInformation *, int n);
    static int SetUpdateGhostLevel(vtkInformation *, int n);
    int SetUpdateTimeStep(int port, double time);
    static int SetUpdateTimeStep(vtkInformation *, double time);

The following new methods were added:

### vtkAlgorithm:

    int Update(int port, vtkInformationVector* requests);
    int Update(vtkInformation* requests);
    int UpdatePiece(int piece, int numPieces, int ghostLevels, int*
extents=0);
    int UpdateExtent(int piece, int numPieces, int ghostLevels, int*
extents=0);
    int UpdateTimeStep(double time,
        int piece=-1, int numPieces=1, int ghostLevels=0, int* extents=0);

### vtkStreamingDemandDrivenPipeline:

    int Update(int port, vtkInformationVector* requests);

The main reason behind these changes is to make requesting a particular
time step or a particular spatial subset (extent or pieces) during an
update easier and more predictable. Prior to these changes, the following
is the best way to request a subset during update:

    vtkNew<vtkRTAnalyticSource> source;
    // Set some properties of source here
    source->UpdateInformation();
    source->SetUpdateExtent(0, 5, 0, 5, 2, 2);
    source->Update();

Note that the following will not work:

    vtkNew<vtkRTAnalyticSource> source;
    // Set some properties of source here
    // source->UpdateInformation(); <-- this was commented out
    source->SetUpdateExtent(0, 5, 0, 5, 2, 2);
    source->Update();

This is because when the output of an algorithm is initialized, all request
meta-data stored in its OutputInformation is removed. The initialization of
the output happens during the first *RequestInformation*, which is why
`UpdateInformation()` needs to be called before setting any request values.
To make things more complicated, the following will also not work:

    vtkNew<vtkRTAnalyticSource> source;
    // Set some properties of source here
    source->UpdateInformation();
    source->SetUpdateExtent(0, 5, 0, 5, 2, 2);
    source->Modified();
    source->Update();

This is because during *RequestInformation*, the extent and piece requests
are initialized to default values (which is the whole dataset) and
*RequestInformation* is called during update if the algorithm has been
modified since the last information update.

This necessary sequence of calls has been mostly tribal knowledge and is
very error prone. To simplify pipeline updates with requests, we introduced
a new set of methods. With the new API, our example would be:

    vtkNew<vtkRTAnalyticSource> source;
    int updateExtent[6] = {0, 5, 0, 5, 2, 2};
    // Set some properties of source here
    source->UpdateExtent(updateExtent);

To ask for a particular time step from a time source, we would do something
like this:

    vtkNew<vtkExodusIIReader> reader;
    // Set properties here
    reader->UpdateTimeStep(0.5);
    // or
    reader->UpdateTimeStep(0.5, 1, 2, 1);

The last call asks for time value 0.5 and the first of two pieces with one
ghost level.

The new algorithm also supports directly passing a number of keys to make
requests:

    typedef vtkStreamingDemandDrivenPipeline vtkSDDP;
    vtkNew<vtkRTAnalyticSource> source;
    int updateExtent[6] = {0, 5, 0, 5, 2, 2};
    vtkNew<vtkInformation> requests;
    requests->Set(vtkSDDP::UPDATE_EXTENT(), updateExtent, 6);
    reader->Update(requests.GetPointer());

This is equivalent to:

    typedef vtkStreamingDemandDrivenPipeline vtkSDDP;
    vtkNew<vtkRTAnalyticSource> source;
    int updateExtent[6] = {0, 5, 0, 5, 2, 2};
    source->UpdateInformation();
    source->GetOutputInformation(0)->Set(vtkSDDP::UPDATE_EXTENT(),
updateExtent, 6);
    reader->Update();

We expect to remove the deprecated methods in VTK 8.0.

On Wed, Feb 24, 2016 at 3:01 AM, Jé Velut <jerome.velut at gmail.com> wrote:

> Dear all,
>
> I am struggling with the pipeline mechanism.
> I wrote an image reader that wraps the ITK gdcm reader. When I change the
> directory,
> the reader does update. However, if the extent of the second volume is
> larger than the
> first one, I get the warning message :
>
> ERROR: In
> C:\Users\Jerome\Dev\VTK\vtk-src\Common\ExecutionModel\vtkStreamingDemandDrivenPipeline.cxx,
> line 857
> vtkCompositeDataPipeline (000002913075DB70): The update extent specified
> in the information for output port 0 on algorithm
> vtkITKGDCMImageReader(000002913074A470) is 0 255 0 255 0 255, which is
> outside the whole extent 0 255 0 255 0 197.
>
> Strangely, I wrote a simple test for this reader and the warning is not
> thrown. The test set the file path, updates, then changes the file path and
> updates again. The warning appears in a more complicated pipeline.
>
> The odd is that I implemented the RequestUpdateExtent, that simply returns
> the Superclass::RequestUpdateExtent result. In the simple test, this
> function is called at each pipeline update. In the full application, it is
> not called the second time (while requestInformation is correctly
> called...).
>
> I guess the pipeline does not notify correctly the reader to change the
> update extent. But why?
> I found this thread which may be close to my issue :
>
> http://markmail.org/search/?q=update_extent+not+updated#query:update_extent%20not%20updated+page:1+mid:xmi3dp3xqbnp2hzv+state:results
>
> Thanks a lot !
> Jerome
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160224/78a9082d/attachment-0001.html>