<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Further to what ken wrote....<br>
"Many VTK algorithms, including stream tracing, require your mesh to be
conforming. "<br>
<br>
in fact the stream tracer, uses FindCell to locate the integration
position - this can take a cell as start point and uses the neighbours
to locate the next cell as the point moves ....which is (I think) why
it fails on your data. <br>
<br>
you can rewrite the core of the stream tracer to use a locator instead
of straight findcell to make it work on your data. (Assuming this is
preferable 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...<br>
<br>
JB<br>
<blockquote
cite="mid:0BA5ECE2D409814B9A324DDEDA2C29FC1F9A3DA57D@ES04SNLNT.srn.sandia.gov"
type="cite">
<pre wrap="">Stefan,
The idea of a hexahedron having more than 6 neighbors is not allowed. The 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 not to be "water-tight." That is, it is not reasonable to represent 3 collinear points exactly in finite precision numbers. The edge represented by 2 nodes 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 the top and bottom nodes. The other two cells each have a face with the middle node. What if you moved that middle node a little to the right? You would no longer consider these neighbors, right? That would be a geometric change, not a topological change. The connectivity should be based entirely on the 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 of these interfaces, it will assume that the stream left the mesh and terminate that stream.
-Ken
</pre>
<blockquote type="cite">
<pre wrap="">-----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
</pre>
</blockquote>
<pre wrap=""><!---->
_______________________________________________
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>
</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>