<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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 <i>static</i>. <br>
<br>
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).<br>
<br>
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.)<br>
<br>
Up until now, I have always set the information key in the algorithm,
but I intend to now move some functionality into the executive.<br>
<br>
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.<br>
<br>
thanks<br>
<br>
JB<br>
<br>
<pre class="moz-signature" cols="78">--
John Biddiscombe, email:biddisco @ cscs.ch
<a class="moz-txt-link-freetext"
href="http://www.cscs.ch/about/BJohn.php">http://www.cscs.ch/about/BJohn.php</a>
CSCS, Swiss National Supercomputing Centre | Tel: +41 (91) 610.82.07
Via Cantonale, 6928 Manno, Switzerland | Fax: +41 (91) 610.82.82</pre>
</body>
</html>