[vtkusers] vtkMeshQuality broken?

[Dominik Szczerba]

On Thursday 05 April 2007 05:06, you wrote:
> 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.

There are 2 things here, inconsistent orientation and direction of 
orientation. While I am not so much defending the former, I have 2 FEM tools 
which require opposite orientations. Therefore I prefer the idea of 
separating tasks: calculating quality is one thing and checking the 
orientation is another.

>
> > ...  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.

OK, a switch to disregard the orientation, possibly off by default, is a 
reasonable solution.

>
> > 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

There is interest at least from my side.

Thanks a lot,
Dominik

> 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

-- 
Dominik Szczerba, PhD
Computer Vision Lab CH-8092 Zurich
http://www.vision.ee.ethz.ch/~domi