<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
just add this to filters.xml<br>
<br>
<br>
<SourceProxy name="Delaunay3D" class="vtkDelaunay3D"><br>
<InputProperty<br>
name="Input"<br>
command="SetInputConnection"><br>
<ProxyGroupDomain name="groups"><br>
<Group name="sources"/><br>
<Group name="filters"/><br>
</ProxyGroupDomain><br>
<DataTypeDomain name="input_type"><br>
<DataType value="vtkPointSet"/><br>
</DataTypeDomain><br>
</InputProperty><br>
<br>
<DoubleVectorProperty<br>
name="Tolerance"<br>
command="SetTolerance"<br>
number_of_elements="1"<br>
default_values="0.001"><br>
<DoubleRangeDomain name="range" min="0.0" max="1.0" /><br>
</DoubleVectorProperty><br>
<br>
<DoubleVectorProperty<br>
name="Alpha"<br>
command="SetAlpha"<br>
number_of_elements="1"<br>
default_values=".03"><br>
<DoubleRangeDomain name="range" min="0.0" max="0.1" /><br>
</DoubleVectorProperty><br>
<br>
<DoubleVectorProperty<br>
name="Offset"<br>
command="SetOffset"<br>
number_of_elements="1"<br>
default_values="2.5"><br>
<DoubleRangeDomain name="range" min="2.5" max="10.0" /><br>
</DoubleVectorProperty><br>
<br>
<IntVectorProperty<br>
name="BoundingTriangulation"<br>
command="SetBoundingTriangulation"<br>
number_of_elements="1"<br>
default_values="0"><br>
<BooleanDomain name="bool"/><br>
</IntVectorProperty><br>
<!-- End Delaunay3D --><br>
</SourceProxy><br>
<br>
<br>
<br>
<br>
Moreland, Kenneth wrote:
<blockquote
cite="mid:0BA5ECE2D409814B9A324DDEDA2C29FC1F9A3DA5BF@ES04SNLNT.srn.sandia.gov"
type="cite">
<pre wrap="">Does anyone on the list have a plugin for 3D Delaunay triangulation?
Delaunay triangulation is a straightforward (although often slow) way to add connectivity to a collection of points. VTK has a 3D Delaunay triangulation filter, but it is not exposed in ParaView. Perhaps it should be. I think this issue has come up before.
Stefan, you say you are not much of a programmer, but a more ideal solution would be to triangulate (that is, break into tetrahedra) your hexahedra so that the faces match up properly. You have not described how this mesh is created, but you might have some auxiliary knowledge that makes the meshing problem easier.
-Ken
</pre>
<blockquote type="cite">
<pre wrap="">-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:murphy.stefan@gmail.com">murphy.stefan@gmail.com</a> [<a class="moz-txt-link-freetext" href="mailto:murphy.stefan@gmail.com">mailto:murphy.stefan@gmail.com</a>] On Behalf
Of Stefan Murphy
Sent: Monday, February 18, 2008 9:45 AM
To: John Biddiscombe
Cc: Moreland, Kenneth; <a class="moz-txt-link-abbreviated" href="mailto:paraview@paraview.org">paraview@paraview.org</a>
Subject: Re: [Paraview] Re: Stream tracing
To be honest, I am not much of a programmer, and I would rather not
get into the guts of ParaView. Also, it would be preferable for me and
my group to use a stable release version of ParaView.
Is there anything I can do with scattered points? Since this is how my
data is stored in my program, it would be very desirable for me.
On Feb 18, 2008 12:16 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=""> Further to what ken wrote....
"Many VTK algorithms, including stream tracing, require your mesh to be
conforming. "
in fact the stream tracer, uses FindCell to locate the integration
</pre>
</blockquote>
<pre wrap="">position
</pre>
<blockquote type="cite">
<pre wrap="">- this can take a cell as start point and uses the neighbours to locate
</pre>
</blockquote>
<pre wrap="">the
</pre>
<blockquote type="cite">
<pre wrap="">next cell as the point moves ....which is (I think) why it fails on your
data.
you can rewrite the core of the stream tracer to use a locator instead
</pre>
</blockquote>
<pre wrap="">of
</pre>
<blockquote type="cite">
<pre wrap="">straight findcell to make it work on your data. (Assuming this is
</pre>
</blockquote>
<pre wrap="">preferable
</pre>
<blockquote type="cite">
<pre wrap="">to re-dividing your mesh to get a conforming one!) - It might only be
vtkInterpolatedVelocityField that needs work, rather than the tracer
itself.....Berk will know for sure...
JB
Stefan,
The idea of a hexahedron having more than 6 neighbors is not allowed.
</pre>
</blockquote>
<pre wrap="">The
</pre>
<blockquote type="cite">
<pre wrap="">mesh example you gave is one that is not "conforming" (or not consistent
depending on your nomenclature). Many VTK algorithms, including stream
tracing, require your mesh to be conforming. There are multiple problems
that occur with non-conforming meshes. As Berk mentioned, the mesh tends
</pre>
</blockquote>
<pre wrap="">not
</pre>
<blockquote type="cite">
<pre wrap="">to be "water-tight." That is, it is not reasonable to represent 3
</pre>
</blockquote>
<pre wrap="">collinear
</pre>
<blockquote type="cite">
<pre wrap="">points exactly in finite precision numbers. The edge represented by 2
</pre>
</blockquote>
<pre wrap="">nodes
</pre>
<blockquote type="cite">
<pre wrap="">and the edges with 3 nodes usually do not match up perfectly, leading to
"cracks" in the mesh.
The second large problem is that connectivity is ill-defined. In your
example, is the large cell really a neighbor with the two smaller cells?
They do not actually share faces. The large cell has a face connecting
</pre>
</blockquote>
<pre wrap="">the
</pre>
<blockquote type="cite">
<pre wrap="">top and bottom nodes. The other two cells each have a face with the
</pre>
</blockquote>
<pre wrap="">middle
</pre>
<blockquote type="cite">
<pre wrap="">node. What if you moved that middle node a little to the right? You
</pre>
</blockquote>
<pre wrap="">would no
</pre>
<blockquote type="cite">
<pre wrap="">longer consider these neighbors, right? That would be a geometric
</pre>
</blockquote>
<pre wrap="">change,
</pre>
<blockquote type="cite">
<pre wrap="">not a topological change. The connectivity should be based entirely on
</pre>
</blockquote>
<pre wrap="">the
</pre>
<blockquote type="cite">
<pre wrap="">topology. Trying to introduce geometric position into the connectivity
computations opens a Pandora's box of problems.
In short, VTK does not, and cannot, consider these mismatched faces
neighbors. In the case of the stream tracer, if the stream reaches one
</pre>
</blockquote>
<pre wrap="">of
</pre>
<blockquote type="cite">
<pre wrap="">these interfaces, it will assume that the stream left the mesh and
</pre>
</blockquote>
<pre wrap="">terminate
</pre>
<blockquote type="cite">
<pre wrap="">that stream.
-Ken
-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:paraview-bounces+kmorel=sandia.gov@paraview.org">paraview-bounces+kmorel=sandia.gov@paraview.org</a> [<a class="moz-txt-link-freetext" href="mailto:paraview">mailto:paraview</a>-
<a class="moz-txt-link-abbreviated" href="mailto:bounces+kmorel=sandia.gov@paraview.org">bounces+kmorel=sandia.gov@paraview.org</a>] On Behalf Of Stefan Murphy
Sent: Sunday, February 17, 2008 10:13 AM
To: <a class="moz-txt-link-abbreviated" href="mailto:paraview@paraview.org">paraview@paraview.org</a>
Subject: [Paraview] Re: Stream tracing
I had a previous post looking for help with a stream tracing problem.
I sent some data to Berk and he said that my problem lies with my
grid. He said: "I am seeing problems with the way you wrote this mesh.
It looks like you are creating duplicate points or something like
that. The mesh is not "water-tight". When you load it in paraview,
change the representation to wireframe. This is supposed to show only
the external surfaces as wireframe. Instead, it shows a lot of
internal boundaries."
I ditched my VTK output routine and adopted some functions that have
been successfully used to create OpenDX files. With this routine I
shouldn't have any issues with duplicate points, etc. With the new
routine I am having the same problem with my mesh. I am wondering if
my problem could have anything to do with the following:
My grid is cartesian and unstructured (vtk cell type 11). There are 6
sides per cell, but it is possible to have more than 6 neighbouring
cells. I attached a picture to show what I mean. I would think this is
a common thing with unstructured cartesian grids, but I am starting to
scrape the bottom of the barrel here and I am wondering if anyone
thinks this could be a problem.
Has anyone been successful in implementing my type of grid in ParaView
before?
Stefan
_______________________________________________
ParaView mailing list
<a class="moz-txt-link-abbreviated" href="mailto:ParaView@paraview.org">ParaView@paraview.org</a>
<a class="moz-txt-link-freetext" href="http://www.paraview.org/mailman/listinfo/paraview">http://www.paraview.org/mailman/listinfo/paraview</a>
--
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>
</blockquote>
</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/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>