<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=windows-1252"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
David <br>
<blockquote
cite="mid:e85d6c9a0903120940i307d74fek35870cff8fcd6119@mail.gmail.com"
type="cite">
<pre wrap="">
I say we change DATA_GEOMETRY_UNMODIFIED to GEOMETRY_STATIC and use
PRESERVES_GEOMETRY for the filter flag. We should also use
TOPOLOGY_STATIC and PRESERVES_TOPOLOGY as the case may be.
</pre>
</blockquote>
Good. PRESERVES_GEOMETRY sounds just right. I have added code to my own
Xdmf stuff for both geometry and topology STATIC , and using preserve_*
will be great. I'll look at the executive changes you've made. I was
hoping you had looked at this issue. Perhaps in a couple of months when
I return to this we can collaborate on getting an implementation that
fits the majority of use cases and integrates nicely with the rest of
vtk/paraview.<br>
<br>
Gerrick<br>
<br>
In your reader/filter use a vtkSmartPointer<data(set) type> to
hold a reference to whatever data (mesh/attribute etc) you want to
re-use. Later when you need to export it, use ShallowCopy during
RequestData to copy the cached stuff to the output. Always keep a copy
of the stuff internal - don't keep the actual output cached, but a copy
of it (or rather, don't export the actual data, but a shallow copy of
it), using shallow copy saves memory consumption. <br>
<br>
JB<br>
<br>
<blockquote
cite="mid:e85d6c9a0903120940i307d74fek35870cff8fcd6119@mail.gmail.com"
type="cite">
<pre wrap="">
See the changes I made a few months ago to
vtkStreamingDemandDrivenPipeline and, as soon as the code freeze is
over, TestPriorityStreaming. The change preserves attribute,
geometric, and or topological information across filters when it is
safe to do so. I think it will be helpful when we implement
intelligent caching.
cheers,
Dave DeMarle
On Thu, Mar 12, 2009 at 12:13 PM, John Biddiscombe <a class="moz-txt-link-rfc2396E" href="mailto:biddisco@cscs.ch"><biddisco@cscs.ch></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Gerrick
I've been working on some aspects of this (“DATA_GEOMETRY_UNMODIFIED” in
particular), but it is not used by anyone other than me as far as I know.
DATA_GEOMETRY_UNMODIFIED would be what you want, except that
1) It should be GEOMETRY_STATIC and should be set by the reader. In your
case it wouldn't be any good because if the data changed after 10 steps,
then the flag is lying.
2) No filters support it other than the ones I've customized for my own
needs
3) I'm working on improved ways of handling this, but you won't see anything
for months, specifically, there should be a GEOMETRY_STATIC for sources that
have unchanging geometry (over time), but filters which pass geometry
through from source to sink unchanged would need a separate key (Like
GEOMETRY_UNMODIFIED, but with a better name). I haven't settled on a
stratagy that I'm happy with yet.
So in short, unless you want to get quite deep into vtk internals, "no" you
can't really do what you want.
I have written data into xdmf and modified the vtk read/writers to allows me
to re-use meshes over time steps - but it's not yet ready for public
consumption, when it is stable and useful, I'll let you know.
Perhaps someone else out there has made some progress on this front?
JB
Hi All,
I have a temporal data that changes structure less frequently than the
properties on the structure. For instance in 100 timesteps the structure may
only change once every ten timesteps.
Are there ways to handle this in VTK? Currently I re-create my mesh every
time step but I think I can make things faster by only changing the
properties when needed and caching the structure.
I saw some posts on the developer list about setting the
“DATA_GEOMETRY_UNMODIFIED” flag but I couldn’t quite follow along. Also,I’m
still on vtk 5.2.1 rather than cvs head.
Gerrick
________________________________
_______________________________________________
Powered by <a class="moz-txt-link-abbreviated" href="http://www.kitware.com">www.kitware.com</a>
Visit other Kitware open-source projects at
<a class="moz-txt-link-freetext" href="http://www.kitware.com/opensource/opensource.html">http://www.kitware.com/opensource/opensource.html</a>
Please keep messages on-topic and check the VTK FAQ at:
<a class="moz-txt-link-freetext" href="http://www.vtk.org/Wiki/VTK_FAQ">http://www.vtk.org/Wiki/VTK_FAQ</a>
Follow this link to subscribe/unsubscribe:
<a class="moz-txt-link-freetext" href="http://www.vtk.org/mailman/listinfo/vtkusers">http://www.vtk.org/mailman/listinfo/vtkusers</a>
--
John Biddiscombe, email:biddisco @ cscs.ch
<a class="moz-txt-link-freetext" href="http://www.cscs.ch/">http://www.cscs.ch/</a>
CSCS, Swiss National Supercomputing Centre | Tel: +41 (91) 610.82.07
Via Cantonale, 6928 Manno, Switzerland | Fax: +41 (91) 610.82.82
_______________________________________________
Powered by <a class="moz-txt-link-abbreviated" href="http://www.kitware.com">www.kitware.com</a>
Visit other Kitware open-source projects at
<a class="moz-txt-link-freetext" href="http://www.kitware.com/opensource/opensource.html">http://www.kitware.com/opensource/opensource.html</a>
Please keep messages on-topic and check the VTK FAQ at:
<a class="moz-txt-link-freetext" href="http://www.vtk.org/Wiki/VTK_FAQ">http://www.vtk.org/Wiki/VTK_FAQ</a>
Follow this link to subscribe/unsubscribe:
<a class="moz-txt-link-freetext" href="http://www.vtk.org/mailman/listinfo/vtkusers">http://www.vtk.org/mailman/listinfo/vtkusers</a>
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<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/">http://www.cscs.ch/</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>