Node pick failing for mesh with degenerate hexes

[biagas]

Describe the bug

Node pick of a mesh with degenerate hexes will often fail, yielding wrong results or no results at all.

Traced the problem to a call within vtkVisItCellLocator https://github.com/visit-dav/visit/blob/a4573a340ffba49b95ba2bd72bf8ba5a3f9ba842/src/visit_vtk/lightweight/vtkVisItCellLocator.C#L645-L646

which in turn calls https://github.com/visit-dav/visit/blob/a4573a340ffba49b95ba2bd72bf8ba5a3f9ba842/src/visit_vtk/lightweight/vtkCellIntersections.C#L690-L691

The intersection point returned by this method did not coincide with where I visually placed my mouse pick (in my case the z component came back zero when it should have been closer to 1).

As a test, I modified the logic in vtkVisItCellLocator to instead call vtkCell::IntersectWithLine and achieved better results with the sample data.

I looked into the differences between our methods and the individual vtkCell methods, and for this use-case (degen hexes), the main differences appear to be in how the quad surfaces of the hex are triangulated (vtkCellIntersections::QuadIntersectWithLine vs vtkQuad::IntersectWithLine) and how the intersection of the triangle is determined (vtkCellIntersections::TriangleIntersectWithLine vs vtkTriangle::IntersectWithLine).

Not sure at this point whether the quad or the triangle differences are the most significant.

I also don't recall the reason we introduced vtkCellIntersections class instead of using vtkCell methods. Possibly the quad-triangulation problem. I know we've had problems in the past with very skewed quads.

To Reproduce

Open one of the sample files provided (.silo or .visit), create a mesh plot and attempt node pick with the mouse interaction. You may want to add a label plot of the mesh with 'nodes' instead of 'cells' option just to see if the resultant pick information corresponds to the node ids.

Attachments

@markcmiller86 created these silo files for testing. They are single-cell files. DegenHexSiloFiles.tar.gz

Data provided by @nDimensionalSpace when the bug was reported: DegenNodePicking.tar.gz

[markcmiller86]

I wonder if transform-manager detected these cases (which would require a problem-sized traversal of the mesh elements) and converted to their actual zoo type elements, that would be useful?

Also, it occurs to me that degeneracy can be achieved in two ways. One way is topologically...that is ensuring the ints (node ids) in the nodelist for a degenerate hex repeat node ids. That is what the cases above are.

The other way geometrically...that is for the coordinate arrays associated with the nodes to repeat coordinate values. The later approach to degeneracy might have different behavior. Am attaching Silo examples of that for comparison.

DegenCoordHexSiloFiles.tar.gz

[markcmiller86]

Pinging @nDimensionalSpace for reference.

[biagas]

TransformManager might be a good way to go if we discover multiple places in VisIt where the degen-hexes cause problems. Otherwise I think handling it in our HexIntersectWithLine might be better, prevent the overhead except when necessary (?)