[Paraview] Re: Stream tracing

[Stefan Murphy]

Thanks a lot for clarifying that for me. I'm glad I know what the
problem is, even though this is going to be a tough one to resolve.

I can only see 2 solutions. The first one would involve combining
cells (and/or splitting cells) to avoid the problem. This would be
very tricky to do, and even if it was possible it would increase
output time and likely data size.

Option 2 is sort of a hail mary. Is there anyway I can output my data
points as the cell center co-ordinates and have ParaView generate a
grid from this?

I have read a few posts about people successfully importing scattered
points, but I'm not sure how to do this, or if I would be able to
incorporate stream tracing.


Stefan



On Feb 18, 2008 11:32 AM, Moreland, Kenneth <kmorel at sandia.gov> wrote:
> 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
>
>
> > -----Original Message-----
> > From: paraview-bounces+kmorel=sandia.gov at paraview.org [mailto:paraview-
> > bounces+kmorel=sandia.gov at paraview.org] On Behalf Of Stefan Murphy
> > Sent: Sunday, February 17, 2008 10:13 AM
> > To: paraview at paraview.org
> > 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
>
>