[Paraview] Inaccurate results with Probe filter

Berk Geveci berk.geveci at kitware.com
Wed Mar 20 09:56:58 EDT 2013


Hi Magician,

What you said is inaccurate. ParaView (VTK) uses tetrahedralization and
linear interpolation for very few higher order cells. For many other cell
types including all 1st order cells (tets, hexs, pyramids, wedges etc.) and
2nd order cells, VTK actually uses proper basis functions for interpolating
and computing derivatives. The cell in question here is a wedge and here
are the basis functions used by VTK in parametric space:

void vtkWedge::InterpolationFunctions(double pcoords[3], double sf[6])
{
  sf[0] = (1.0 - pcoords[0] - pcoords[1]) * (1.0 - pcoords[2]);
  sf[1] = pcoords[0] * (1.0 - pcoords[2]);
  sf[2] = pcoords[1] * (1.0 - pcoords[2]);
  sf[3] = (1.0 - pcoords[0] - pcoords[1]) * pcoords[2];
  sf[4] = pcoords[0] * pcoords[2];
  sf[5] = pcoords[1] * pcoords[2];
}

If you are interested in finding out which basis functions are used for
each cell, check out vtkCELLNAME.cxx in VTK/Common/DataModel in current
VTK/ParaView code base.

Currently, VTK uses linear interpolation in time for particle path
calculation but it is possible to use higher order interpolation if one is
willing to load more than 2 time steps - which is difficult due to memory
constraints.

I suspect what you are referring to is how VTK handles polyhedral cells. We
have made some initial attempts to support polyhedron but VTK's support is
still pretty immature in this area. I should mention that VTK still does
not use tetrahedralization for interpolating polyhedras. Or you might be
referring to the fact that VTK uses subdivision to perform certain
filtering operations such as contouring, which is true for some cell types.
This is completely different than interpolation.

The issue in question here has nothing to do with interpolation. There is a
bug in the probing logic that causes the interpolation to happen in block
that contains triangles in the multi-block dataset. For some reason I
haven't determined yet, the code prefers the block with triangles rather
than the block with 3D cells when finding the cell in which the probe point
falls. This happens despite the fact that the triangle is actually quite
far from the point. When that block is removed, the probe produces results
identical (within floating point accuracy) to FieldView. Folks that do not
have a mix of 2D and 3D cells in a multi-block structure should not see
this issue.

Best,
-berk



On Tue, Mar 19, 2013 at 10:17 PM, Magician <f_magician at mac.com> wrote:

> Sorry.
> I forgot to add an address of PV mailing list.
>
>
> Magician
>
>
> On 2013/03/20, at 10:33, Magician wrote:
>
> > Hi Tony,
> >
> >
> > I discussed similar problems.
> > <http://www.paraview.org/pipermail/paraview/2012-June/025273.html>
> >
> > The interpolation and integration method (both space and time domain)
> > of ParaView are very simple, but not ideal.
> > ParaView splits all cells into tetrahedra or triangle and
> > interpolate values with linear algorithm.
> > I haven't research FIELDVIEW's method yet, but it may be different from
> PVs.
> >
> >
> > Magician
> >
> >
> > On 2013/03/20, at 4:13, paraview-request at paraview.org wrote:
> >
> >> Hi Tony,
> >>
> >> What kind of cells are these? Can you make the data available to us?
> >>
> >> -berk
> >>
> >>
> >> On Tue, Mar 19, 2013 at 12:16 PM, Tony McDaniel <tonymcdaniel at gmail.com
> >wrote:
> >>
> >>> I'm using the Probe Location filter to extract data from a 3D CFD
> solution
> >>> for an internal flow, and I'm not getting the data that I should be for
> >>> some (but not all) of the points. The dataset is approximately 7
> million
> >>> nodes saved in Ensight format.
> >>>
> >>> I'm comparing the data returned by Paraview to the data at the same
> >>> locations in FieldView. For licensing reasons, I would prefer to use
> >>> Paraview for this research, but I also need accurate solutions.
> >>>
> >>> For two representative probe locations, I have the following results:
> >>> x       y       z       pv_density  fv_density  pv_pressure fv_pressure
> >>> 0.3912    -0.0376    -0.0566    0.9040      0.9040        67779.9
> >>> 67779.9
> >>> 0.3912    -0.0426    -0.0516    0.8275      0.8623        65849.0
> >>> 66176.3
> >>>
> >>> The first point matches precisely between Paraview and FieldView.
> However,
> >>> the second point is substantially different. In addition, the velocity
> at
> >>> point two is {0,0,0} indicating that the point is on the boundary,
> though
> >>> it is not actually.
> >>>
> >>> Looking at color plots in Paraview, the color under the point location
> >>> clearly matches the numbers from FieldView. I've uploaded plots showing
> >>> pressure in the plane containing the two locations here:
> >>> https://dl.dropbox.com/u/**744216/probe1.png<
> https://dl.dropbox.com/u/744216/probe1.png>
> >>> https://dl.dropbox.com/u/**744216/probe2.png<
> https://dl.dropbox.com/u/744216/probe2.png>
> >>>
> >>> The values are wrong for points that are close to the boundary, and
> match
> >>> FieldView for points away from the boundary. I have also tried
> importing
> >>> the locations from a CSV file and using the Resample Dataset and get
> the
> >>> same values.
> >>>
> >>> Can anyone shed light on why this is happening?
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.paraview.org/pipermail/paraview/attachments/20130320/5d01741e/attachment-0001.htm>


More information about the ParaView mailing list