[vtkusers] vtkMeshQuality broken?

[David C Thompson]

Dominik wrote:
> Oh yes, after flipping my tets I seem to be geting the old numbers. I don't 
> believe these should depend on tet orientation though. I once raised this 
> issue with MathWorld (and was finally agreed with). Orientation is not always 
> (needed to be) maintained ...
Theoretically no, but practically it is often a sign of deeper trouble.

> ...  and quality as radius ratios by definition is 
> always positive. If one wants one can make an extra separate check, 
> otherwise, there might be an unnecessary frustration.
A couple of people on the Verdict project have answered my question
about the inconsistency between the documentation and the behavior; they
would like to keep the radius ratio reporting invalid values for
negatively oriented tets but aren't opposed to having a setting that
would report proper values regardless of orientation. Philippe and I
will most probably add this feature in the not-too-distant future.

> PS. I could not find a vtk class to flip tets, small issue though.
Ah, it (vtkFixTetrahedra) is actually in a repository here at Sandia. I
have permission from the author to migrate it to VTK if
1. there's any interest, and
2. Kitware approves.

	David

> 
> 
> 
> On Friday 30 March 2007 03:12, you wrote:
> > > The values in quality.GetOutput().GetCellData().GetScalars("Quality") are
> > > not OK, 1e30 in my case. Setting VolumeOn() and RatioOn() seem to do give
> > > some numbers, but they seem more (signed) volume than quality. I am
> > > pretty sure I have made no changes to this code for months.
> >
> > I ran the filter on tetraMesh.vtk in VTKData and noticed that the 1e30
> > is returned for each and every cell with negative volume (and no
> > others). This is probably a result of switching to use the quality
> > metrics computed by the Verdict library as Philippe Pébay announced a
> > month of so ago. Since this behavior (returning an invalid value for
> > inverted tets) doesn't match the documentation for the Verdict library,
> > I will take up how best to fix it with the Verdict folks. I would not be
> > surprised if they wish to keep the current behavior and adjust the
> > documentation since negative volumes often indicate serious trouble with
> > the algorithm that produced them. In that case, you should orient
> > tetrahedra properly before sending them to vtkMeshQuality. I believe
> > there's a filter that will reorient tets but I don't remember the name
> > of it offhand.
> >
> > Thanks for the heads up on the python test; it needs to be updated. I
> > don't think it could have worked for over 2 years given that it assumes
> > the output mesh's field data has scalars set. (We do produce field data
> > arrays, but there are 4 of them -- one for each element type supported
> > -- each of which has a 5-tuple holding descriptive statistics, instead
> > of a copy of the per-cell results.)
> >
> > 	David
> >
> > > Thanks for any hints,
> > > Dominik
> > >
> > > On Friday 30 March 2007 00:08, David C Thompson wrote:
> > > > > vtkMeshQuality does not work for me any longer (both C++ and python).
> > > > > I do as simple as: vtkUnstructuredGridReader -> vtkMeshQuality ->
> > > > > vtkUnstructuredGridWriter with setting Input/Output connections as
> > > > > usual. It always worked now not anymore. In the docs I read about
> > > > > some compatibility issues (VolumeOn, RatioOn()) - were there recent
> > > > > changes? The test referred to there (meshQuality.py) does not work.
> > > >
> > > > Can your provide more information about what doesn't work? Does the
> > > > filter not compile, not run, yield no results, or incorrect results?
> > > >
> > > > 	Thanks,
> > > > 	David
>