[Paraview] Inaccurate results with Probe filter

Tue Mar 26 13:26:55 EDT 2013

For those interested, a fix for this is now in VTK. It should propagate to
ParaView with a week or two.

Best,
-berk

On Wed, Mar 20, 2013 at 9:56 AM, Berk Geveci <berk.geveci at kitware.com>wrote:

> 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/20130326/ef5edc4a/attachment-0001.htm>