[vtkusers] vtkMeshQuality broken?

[Pebay, Philippe P]

I am confirming what David wrote: I will add (in a not too distant future) the ability
to decide whether or not orientation should be checked. I agree with Dominik that, by definition,
the radius ratio is orientation-independent. But, on the other hand, having inverted elements can
lead to mayhem with some FE solvers. That's why Verdict is set the way it is (it was initially a tool
for post-processing of mesh generators). 

In any event, I will take care of this, soon -- but not this week :)

Philippe
 

-----Original Message-----
From: Thompson, David C
Sent: Wed 4/4/2007 9:06 PM
To: Dominik Szczerba
Cc: vtkusers at vtk.org; Pebay, Philippe P
Subject: Re: [vtkusers] vtkMeshQuality broken?
 
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
> 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20070405/9e24f853/attachment.htm>