[vtk-developers] vtkDataObject::DATA_GEOMETRY_UNMODIFIED()

[David E DeMarle]

I've been thinking about something similar lately too.

I've recently implemented "A modular extensible visualization system
architecture for culled prioritized data streaming." Ahrens et al,
Proceedings of SPIE, Jan 2007, in ParaView. For that I need the
pipeline to keep track of meta information about the data too. For
example, if the reader can provide scalar ranges, a contour filter can
quickly reject whole pieces of the data before it actually has to
process the cells in them. Similarly a clipping plane filter can
quickly reject pieces for which the geometric extent is known. The
optimization depends on the ability of the the pipeline to keep
similar meta information around and to make sure that it stays valid.

I have been thinking about adding four new information keys,
DATA_TOPOLOGY_UNCHANGED, DATA_GEOMETRY_UNCHANGED,
DATA_POINT_ARRAYS_UNCHANGED and DATA_CELL_ARRAYS_UNCHANGED. Algorithms
which know that they will not modify those parts of their input data
as they produce output data should flag those keys which will make the
pipeline will propagate them and any related meta data holding
information objects. Downstream filters can use the presence of the
keys to optimize their own behavior.

By default filters should not flag those keys, in which case they will
not be propagated, and downstream algorithms will do the slow but
correct thing.

That's my $0.02, for all it is worth.
Dave DeMarle

2008/7/25 Moreland, Kenneth <kmorel at sandia.gov>:
> 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
>
> _______________________________________________
> vtk-developers mailing list
> vtk-developers at vtk.org
> http://www.vtk.org/mailman/listinfo/vtk-developers
>
>