# Marking algorithm output as unchanged

**URL:** https://discourse.vtk.org/t/marking-algorithm-output-as-unchanged/3210
**Category:** Support
**Created:** [May 5, 2020, 9:59am UTC](https://discourse.vtk.org/t/marking-algorithm-output-as-unchanged/3210 "2020-05-05T09:59:28Z")
**Posts on this page:** 1
**Page:** 1

<div class="post-metadata">

### Author: ![BetaRavener](https://discourse.vtk.org/user_avatar/discourse.vtk.org/betaravener/32/1729_2.png) [@BetaRavener](https://discourse.vtk.org/u/BetaRavener)
#### Post date: [May 5, 2020, 9:59am UTC](https://discourse.vtk.org/t/marking-algorithm-output-as-unchanged/3210/1 "2020-05-05T09:59:28Z")

</div>

Hi. I have a situation in which I have a two filters and a time-aware source. Source (A) is connected to first filter (B), which filters the data based on some criteria. Output of B is connected to computationally heavy filter ©, which takes several seconds to execute. I update filter C with `UpdateTimeStep` over several times to produce few images.

Now, in lot of cases, even if output of the source changes, the filtered data remains the same and so B will produce same output as before and I’m able to check for this. However, filter C still executes because the request was made from it. I would like to prevent this in a way that I don’t have to break up pipeline, something like setting flag on the request or something telling that output of filter B didn’t change.

I’ve tried not setting out output in RequestData of filter B, but that doesn’t work as outputs seem to be cleared before RequestData executes, clearing out the previous output. Is this the case and where does it happen? Could it be maybe controlled somehow?

The only solution I see so far is to break up the pipeline between B and C, call `UpdateTimeStep` only on filter B, which would in RequestData set some flag if the data really changed. If so, then call `GetOutputDataObject` on B to get new object and pass it to C with `SetInputData`. This way, C’s input will only appear modified if the B’s output really changed. But I’d say this is far from optimal.