[vtk-developers] vtkDataObject::DATA_GEOMETRY_UNMODIFIED()

[Moreland, Kenneth]

John,

I have a question about the change to the DATA_GEOMETRY_STATIC flag.  If the flag is always set, even on the first execution, then how will downstream filters know when the geometry really does change?  For example, what if the filename in the reader is changed?  What if you change the filter's input between sources that both declare the DATA_GEOMETRY_STATIC flag, but have different geometry.  Also, what happens when ghost cells are requested (and provided)?  Is the geometry still considered static, or is it not static because it has technically changed?

On a less technical note, I'm glad to see you implement this feature.  I've been thinking for some time that the D3 filter should be able to efficiently handle cases where the topology remains fixed, which means that the space partitioning and some of the data transfer could be skipped.  This is certainly the necessary base requirements for that.

There are probably a few filters that could benefit from taking advantage of the static geometry flag.    There are other examples of filters whose operation relies solely on topology such as vtkGeometryFilter, vtkTriangleFilter, and vtkStripper.

-Ken

________________________________
From: vtk-developers-bounces at vtk.org [mailto:vtk-developers-bounces at vtk.org] On Behalf Of John Biddiscombe
Sent: Friday, July 25, 2008 7:55 AM
To: VTK Developers
Subject: [vtk-developers] vtkDataObject::DATA_GEOMETRY_UNMODIFIED()

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.

thanks

JB



--

John Biddiscombe,                            email:biddisco @ cscs.ch

http://www.cscs.ch/about/BJohn.php

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

Via Cantonale, 6928 Manno, Switzerland      | Fax:  +41 (91) 610.82.82
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20080725/d81a3201/attachment.html>