[Paraview] Re: Stream tracing
kmorel at sandia.gov
Mon Feb 18 12:10:32 EST 2008
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.
> -----Original Message-----
> From: murphy.stefan at gmail.com [mailto:murphy.stefan at gmail.com] On Behalf
> Of Stefan Murphy
> Sent: Monday, February 18, 2008 9:45 AM
> To: John Biddiscombe
> Cc: Moreland, Kenneth; paraview at paraview.org
> 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 <biddisco at cscs.ch> wrote:
> > 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
> > - this can take a cell as start point and uses the neighbours to locate
> > 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
> > straight findcell to make it work on your data. (Assuming this is
> > 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.
> > 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
> > to be "water-tight." That is, it is not reasonable to represent 3
> > points exactly in finite precision numbers. The edge represented by 2
> > 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
> > top and bottom nodes. The other two cells each have a face with the
> > 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
> > not a topological change. The connectivity should be based entirely on
> > 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
> > these interfaces, it will assume that the stream left the mesh and
> > 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
> > _______________________________________________
> > ParaView mailing list
> > ParaView at paraview.org
> > http://www.paraview.org/mailman/listinfo/paraview
> > --
> > John Biddiscombe, email:biddisco @ cscs.ch
> > http://www.cscs.ch/about/BJohn.php
> > CSCS, Swiss National Supercomputing Centre | Tel: +41 (91) 610.82.07
> > Via Cantonale, 6928 Manno, Switzerland | Fax: +41 (91) 610.82.82
More information about the ParaView