atom feed3 messages in org.vtk.vtk-developers[vtk-developers] vtkDataObject::DATA_...
FromSent OnAttachments
John BiddiscombeJul 25, 2008 6:54 am 
Moreland, KennethJul 25, 2008 8:36 am 
David E DeMarleJul 25, 2008 12:09 pm 
Subject:[vtk-developers] vtkDataObject::DATA_GEOMETRY_UNMODIFIED()
From:John Biddiscombe (
Date:Jul 25, 2008 6:54:32 am

Some time ago, I added the eponymous information key so that when animating or iterating over time steps, I could flag certain datasets as not having changed - topologically speaking, even though they were produced by a filter which had possibly re-executed - and thus regenerated all pointers/datasets etc. In several of my transient data readers, I cache the geometry and pass out the same mesh with subsequent re-executions of the filter, scalars are changed and I set the DATA_GEOMETRY_UNMODIFIED() flag.

The most advanced usage is the CFX reader which can tell if a block within a multiblock structure is dynamic or static and outputs a multiblock structure with (in one example) 38 volumes, 17 of which are dynamic, 21 are static. 17 therefore have the unmodified flag set. Filters such as TemporalCache and TemporalInterpolator have been tweaked to pass through this flag, so that when the mesh is interpolated to give new time steps between the original ones, it tests to see if the original 2 input meshes (timesteps) are static and if so, outputs static as well.

The particle tracer is the first filter to make use of this flag effectively, and is now capable of constructing BSP trees for the first timestep on all 38 volumes, then for each subsequent step, it shares the BSP structure if static, or constructs a new one if dynamic, it does this independently for each block of the multiblock structure.

The time saving this has produced is very significant. On some of the very large volumes, constructing the BSP tree can take a minute or so, and doing this once, instead of (say) 300 times saves a lot. Additionally, cache information about particles is saved for static meshes between time steps, again improving performance.

I would like to now start pushing this functionality out to other filters, beyond just those of my own experimentation, and my first though is that the key should be renamed to vtkDataObject::DATA_GEOMETRY_STATIC(), my first implementation made an extra assumption that when data first arrived (say timestep 0), it could not be UnModified since it did not exist before, - this made things uneccesarily complicated, but was also intended to cater for filters like (for example) vtkElevationFilter - which modified the output, but leaves the geometry alone - indicating that the geometry was unmodifed - not quite the same as static.

I believe that at the vtkAlgorithm level, a flag such as "this->GeometryNotModified" (with a default value of false) should be added, and the executive adjusted to check the algorithm so that if the input is static and the algorithm has GeometryNotModified, then the information key can be passed automatically. (Filter like Temporal interpolator, can set the flag at run time if the inputs are static, others like elevation filter can set it in the constructor and leave it alone).

Adding this functionality will not help many existing filters, since there are few/none others that operate over time dependent data, though some could be altered to re-use output geometry (caching internally possibly), which would benefit animations, but putting the key setting into the executive will allow data to pass through several filters and remain 'static', thus allowing more complicated optimizations which might not be possible without a 'hand made' pipeline (not very clearly explained, but if you've read this far, then you probably understand anyway). (Note also that having a static flag for a miltiblock filter will not be enough and in fact we need something more like GetGeometryStatic(int index)...I have not thought this case though very well yet.)

Up until now, I have always set the information key in the algorithm, but I intend to now move some functionality into the executive.

If anyone wishes to comment or make suggestions of improvements, then please open up a discussion here. I shan't be checking anything in for a while, but will be experimenting with alternative implementations.




John Biddiscombe, email:biddisco @


CSCS, Swiss National Supercomputing Centre | Tel: +41 (91) 610.82.07

Via Cantonale, 6928 Manno, Switzerland | Fax: +41 (91) 610.82.82