[vtk-developers] Changes to the way the pipeline is updated

Berk Geveci berk.geveci at kitware.com
Fri Jan 15 12:47:28 EST 2016


Hi David,

Thanks :-) I plan on tackling the diamond shaped pipelines in the
medium-future. My plan for that is much more ambitious. I want to make each
pass have an upstream and downstream part. There would be 3 passes:

Static meta-data (same as current Request Information)
Dynamic meta-data (requests go up and dynamic meta-data comes down)
Data (requests go up and data comes down)

So we can do something like this:

* Static meta-data : get time steps
* Dynamic meta-data : request for time step, get whole extent back
* Data : request for sub-extent, get data back.

Currently, this would require whole lot more passes. Plus this would fix
any issues with diamond pipelines because each execution path would happen
with the appropriate update request - so branch-outs in a diamond pipeline
could execute multiple times if each branch asked for different extent.

Cheers,
-berk


On Fri, Jan 15, 2016 at 11:47 AM, David Gobbi <david.gobbi at gmail.com> wrote:

> Hi Berk,  I'll take a look.  Proper initialization, validation, and (in
> the case diamond-shaped pipelines and multiple downstream requests) proper
> combination of update extents is a real headache.  I don't envy you.
> Making the behavior more explicit sounds good.
>
> By the way, I started planning the integration of the SMP image filters a
> couple weeks ago.  It'll hopefully be ready in a couple months.
>
>  - David
>
>
> On Fri, Jan 15, 2016 at 8:57 AM, Berk Geveci <berk.geveci at kitware.com>
> wrote:
>
>> Hi folks,
>>
>> In an effort to address a bug reported on the mailing list, I ended up
>> making a change to the way the pipeline is updated. I made a minor change
>> to the way update behaves but more importantly, I'd like to make an API
>> change that is biggish.
>>
>> Here is how an algorithm is updated currently.
>>
>> anAlgorithm->Update();
>>
>> If you want the algorithm to produce a particular subset in space or
>> time, you need to do this:
>>
>> anAlgorithm->UpdateInformation();
>> anAlgorithm->SetUpdateExtent(0, 2, 0);
>> anAlgorithm->SetUpdateExtent(0, 10, 0, 10, 1, 1);
>> anAlgorithm->SetUpdateTimeStep(0.5);
>> anAlgorithm->Update();
>>
>> If you forget the UpdateInformation() part, this does not work. This is a
>> problem because there are a bunch of disparate methods that need to be
>> documented with information about the order of the method calls. Currently,
>> this is tribal knowledge. The change I need to make to fix the bug reported
>> makes things even more complicated. After the change, this will not work:
>>
>> anAlgorithm->UpdateInformation();
>> anAlgorithm->SetUpdateExtent(0, 2, 0);
>> anAlgorithm->Modified();
>> anAlgorithm->Update();
>>
>> The Modified() call causes the Information pass to execute again, which
>> after my changes initializes the requests to default values (such as (0, 1,
>> 0) for the piece stuff and WHOLE_EXTENT() for the extents). Without this
>> change, there are subtle bugs that come up in filters and mappers. So now,
>> we also need to document that you cannot modify the object  after
>> UpdateInformation() (including calling any Set methods) for this to work.
>>
>> Here is the change I'd like to make:
>>
>> * Deprecate all of the SetUpdateXXX() methods.
>> * Add arguments to Update() that allows passing of requests
>>
>> So the first example would look like:
>>
>> int updateExtent[6] = {0, 10, 0, 10, 1, 1};
>> anAlgorithm->UpdateTimeStep(0.5, 0, 2, 0, updateExtent);
>>
>> There are signatures for:
>>
>> Update(int piece, int numPieces, int ghostLevel);
>> Update(int piece, int numPieces, int ghostLevel, int* updateExtent);
>> UpdateTimeStep(double time);
>> UpdateTimeStep(double time, int piece, int numPieces, int ghostLevel);
>> UpdateTimeStep(double time, int piece, int numPieces, int ghostLevel,
>> int* updateExtent);
>>
>> There is also a more flexible method with this signature:
>>
>> Update(vtkInformation* requests);
>>
>> This allows assigning any arbitrary number of requests for the update
>> pass. For example:
>>
>> vtkNew<vtkInformation> info;
>> info->Set(vtkStreamingDemandDrivenPipeline::UPDATE_TIME_STEP(), 0.5);
>> anAlgorithm->Update(info.GetPointer());
>>
>> Finally, it is still possible to do the "updateInfo -> set request ->
>> update" thing like this:
>>
>> int updateExtent[6] = {0, 10, 0, 10, 1, 1};
>> anAlgorithm->UpdateInformation();
>> vtkInformation* outInfo = anAlgorithm->GetOutputInformation(0);
>> outInfo->Set(vtkStreamingDemandDrivenPipeline::UPDATE_EXTENT(),
>>   updateExtent);
>> // Don't modify the object after this
>> anAlgorithm->Update();
>>
>> This is the advanced use case.
>>
>> Here is the branch that passes all of the tests:
>>
>> https://gitlab.kitware.com/berkgeveci/vtk/commits/setupdateextent-change
>>
>> It is WIP because I need to add some better documentation.
>>
>> What do you think?
>> -berk
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160115/d65ff8a4/attachment.html>


More information about the vtk-developers mailing list