There are problems currently when running some temporal filters in situ. Since the entire time series is not available up straight, temporal filters need to be able to produce a correct output up to the available timesteps, and then to be run on upcoming timesteps using some internal cache. An example of a filter failing in situ is vtkTemporalStatistics
.
However, we should, for performance reasons, still be able to run a filter on the entire time series without having to generate intermediate states, typically when using ParaView without catalyst.
As a consequence, in filters for which it applies, there should be 2 modes: a regular mode (compute all the time steps at once), and an in situ mode (access to incomplete temporal data). In the regular mode, one can just call Update()
to get the output. In situ, one needs to call UpdateTimeStep(double t)
for each time step.
Ideally, there shouldn’t be extra parameters in temporal filters to avoid users producing wrong outputs because they forgot to turn ON the in situ mode inside a filter that needs it. Instead, I propose that we add a new Information key that should be set on source output information in situ. The key would be passed downstream and all filters needing to change how they behave would know when to. We could call it INCOMPLETE_TIME_STEPS
. When set to true, filters for which it applies can cache whatever data they need to cache in order to produce a complete dataset for each time step. An implementation is proposed here.
This key would be automatically set on all sources when using ParaView Catalyst (see implementation here).
An issue arises when setting ON INCOMPLETE_TIME_STEPS
: the filter doesn’t know when to reinitialize its cache. The temporal cache held by concerned filters needs wiped when the user wants to rerun all the timesteps as he changes a parameter in the visualization for example. There is no way to know when a filter gets updated to add a new timestep, or when it does from scratch. To give awareness of such context, I propose to add a new information key that gets set by the executive automatically: WIPE_ALGORITHM_CACHE
. It is set to 1 when any upstream filter has called Modified()
. It gets propagated downstream by the pipeline. When a concerned temporal filter sees it set, it knows to wipe its temporal cache. You can find how it would be implemented and how to use the key here.
Does anyone have any comments or suggestions?