<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7651.59">
<TITLE>RE: [vtkusers] vtkMeshQuality broken?</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<BR>
<P><FONT SIZE=2>I am confirming what David wrote: I will add (in a not too distant future) the ability<BR>
to decide whether or not orientation should be checked. I agree with Dominik that, by definition,<BR>
the radius ratio is orientation-independent. But, on the other hand, having inverted elements can<BR>
lead to mayhem with some FE solvers. That's why Verdict is set the way it is (it was initially a tool<BR>
for post-processing of mesh generators).<BR>
<BR>
In any event, I will take care of this, soon -- but not this week :)<BR>
<BR>
Philippe<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: Thompson, David C<BR>
Sent: Wed 4/4/2007 9:06 PM<BR>
To: Dominik Szczerba<BR>
Cc: vtkusers@vtk.org; Pebay, Philippe P<BR>
Subject: Re: [vtkusers] vtkMeshQuality broken?<BR>
<BR>
Dominik wrote:<BR>
> Oh yes, after flipping my tets I seem to be geting the old numbers. I don't<BR>
> believe these should depend on tet orientation though. I once raised this<BR>
> issue with MathWorld (and was finally agreed with). Orientation is not always<BR>
> (needed to be) maintained ...<BR>
Theoretically no, but practically it is often a sign of deeper trouble.<BR>
<BR>
> ... and quality as radius ratios by definition is<BR>
> always positive. If one wants one can make an extra separate check,<BR>
> otherwise, there might be an unnecessary frustration.<BR>
A couple of people on the Verdict project have answered my question<BR>
about the inconsistency between the documentation and the behavior; they<BR>
would like to keep the radius ratio reporting invalid values for<BR>
negatively oriented tets but aren't opposed to having a setting that<BR>
would report proper values regardless of orientation. Philippe and I<BR>
will most probably add this feature in the not-too-distant future.<BR>
<BR>
> PS. I could not find a vtk class to flip tets, small issue though.<BR>
Ah, it (vtkFixTetrahedra) is actually in a repository here at Sandia. I<BR>
have permission from the author to migrate it to VTK if<BR>
1. there's any interest, and<BR>
2. Kitware approves.<BR>
<BR>
David<BR>
<BR>
><BR>
><BR>
><BR>
> On Friday 30 March 2007 03:12, you wrote:<BR>
> > > The values in quality.GetOutput().GetCellData().GetScalars("Quality") are<BR>
> > > not OK, 1e30 in my case. Setting VolumeOn() and RatioOn() seem to do give<BR>
> > > some numbers, but they seem more (signed) volume than quality. I am<BR>
> > > pretty sure I have made no changes to this code for months.<BR>
> ><BR>
> > I ran the filter on tetraMesh.vtk in VTKData and noticed that the 1e30<BR>
> > is returned for each and every cell with negative volume (and no<BR>
> > others). This is probably a result of switching to use the quality<BR>
> > metrics computed by the Verdict library as Philippe Pébay announced a<BR>
> > month of so ago. Since this behavior (returning an invalid value for<BR>
> > inverted tets) doesn't match the documentation for the Verdict library,<BR>
> > I will take up how best to fix it with the Verdict folks. I would not be<BR>
> > surprised if they wish to keep the current behavior and adjust the<BR>
> > documentation since negative volumes often indicate serious trouble with<BR>
> > the algorithm that produced them. In that case, you should orient<BR>
> > tetrahedra properly before sending them to vtkMeshQuality. I believe<BR>
> > there's a filter that will reorient tets but I don't remember the name<BR>
> > of it offhand.<BR>
> ><BR>
> > Thanks for the heads up on the python test; it needs to be updated. I<BR>
> > don't think it could have worked for over 2 years given that it assumes<BR>
> > the output mesh's field data has scalars set. (We do produce field data<BR>
> > arrays, but there are 4 of them -- one for each element type supported<BR>
> > -- each of which has a 5-tuple holding descriptive statistics, instead<BR>
> > of a copy of the per-cell results.)<BR>
> ><BR>
> > David<BR>
> ><BR>
> > > Thanks for any hints,<BR>
> > > Dominik<BR>
> > ><BR>
> > > On Friday 30 March 2007 00:08, David C Thompson wrote:<BR>
> > > > > vtkMeshQuality does not work for me any longer (both C++ and python).<BR>
> > > > > I do as simple as: vtkUnstructuredGridReader -> vtkMeshQuality -><BR>
> > > > > vtkUnstructuredGridWriter with setting Input/Output connections as<BR>
> > > > > usual. It always worked now not anymore. In the docs I read about<BR>
> > > > > some compatibility issues (VolumeOn, RatioOn()) - were there recent<BR>
> > > > > changes? The test referred to there (meshQuality.py) does not work.<BR>
> > > ><BR>
> > > > Can your provide more information about what doesn't work? Does the<BR>
> > > > filter not compile, not run, yield no results, or incorrect results?<BR>
> > > ><BR>
> > > > Thanks,<BR>
> > > > David<BR>
><BR>
<BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>