<div dir="ltr">Hi Magician,<div><br></div><div style>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:</div>
<div style><br></div><div style><div>void vtkWedge::InterpolationFunctions(double pcoords[3], double sf[6])</div><div>{</div><div> sf[0] = (1.0 - pcoords[0] - pcoords[1]) * (1.0 - pcoords[2]);</div><div> sf[1] = pcoords[0] * (1.0 - pcoords[2]);</div>
<div> sf[2] = pcoords[1] * (1.0 - pcoords[2]);</div><div> sf[3] = (1.0 - pcoords[0] - pcoords[1]) * pcoords[2];</div><div> sf[4] = pcoords[0] * pcoords[2];</div><div> sf[5] = pcoords[1] * pcoords[2];</div><div>}</div>
<div><br></div><div style>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.</div><div style><br></div>
<div style>
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.</div>
<div style><br></div><div style>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.</div>
<div style><br></div><div style>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.</div>
<div style><br></div><div style>Best,</div><div style>-berk</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Mar 19, 2013 at 10:17 PM, Magician <span dir="ltr"><<a href="mailto:f_magician@mac.com" target="_blank">f_magician@mac.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Sorry.<br>
I forgot to add an address of PV mailing list.<br>
<span class=""><font color="#888888"><br>
<br>
Magician<br>
</font></span><div class=""><div class="h5"><br>
<br>
On 2013/03/20, at 10:33, Magician wrote:<br>
<br>
> Hi Tony,<br>
><br>
><br>
> I discussed similar problems.<br>
> <<a href="http://www.paraview.org/pipermail/paraview/2012-June/025273.html" target="_blank">http://www.paraview.org/pipermail/paraview/2012-June/025273.html</a>><br>
><br>
> The interpolation and integration method (both space and time domain)<br>
> of ParaView are very simple, but not ideal.<br>
> ParaView splits all cells into tetrahedra or triangle and<br>
> interpolate values with linear algorithm.<br>
> I haven't research FIELDVIEW's method yet, but it may be different from PVs.<br>
><br>
><br>
> Magician<br>
><br>
><br>
> On 2013/03/20, at 4:13, <a href="mailto:paraview-request@paraview.org">paraview-request@paraview.org</a> wrote:<br>
><br>
>> Hi Tony,<br>
>><br>
>> What kind of cells are these? Can you make the data available to us?<br>
>><br>
>> -berk<br>
>><br>
>><br>
>> On Tue, Mar 19, 2013 at 12:16 PM, Tony McDaniel <<a href="mailto:tonymcdaniel@gmail.com">tonymcdaniel@gmail.com</a>>wrote:<br>
>><br>
>>> I'm using the Probe Location filter to extract data from a 3D CFD solution<br>
>>> for an internal flow, and I'm not getting the data that I should be for<br>
>>> some (but not all) of the points. The dataset is approximately 7 million<br>
>>> nodes saved in Ensight format.<br>
>>><br>
>>> I'm comparing the data returned by Paraview to the data at the same<br>
>>> locations in FieldView. For licensing reasons, I would prefer to use<br>
>>> Paraview for this research, but I also need accurate solutions.<br>
>>><br>
>>> For two representative probe locations, I have the following results:<br>
>>> x y z pv_density fv_density pv_pressure fv_pressure<br>
>>> 0.3912 -0.0376 -0.0566 0.9040 0.9040 67779.9<br>
>>> 67779.9<br>
>>> 0.3912 -0.0426 -0.0516 0.8275 0.8623 65849.0<br>
>>> 66176.3<br>
>>><br>
>>> The first point matches precisely between Paraview and FieldView. However,<br>
>>> the second point is substantially different. In addition, the velocity at<br>
>>> point two is {0,0,0} indicating that the point is on the boundary, though<br>
>>> it is not actually.<br>
>>><br>
>>> Looking at color plots in Paraview, the color under the point location<br>
>>> clearly matches the numbers from FieldView. I've uploaded plots showing<br>
>>> pressure in the plane containing the two locations here:<br>
>>> <a href="https://dl.dropbox.com/u/**744216/probe1.png" target="_blank">https://dl.dropbox.com/u/**744216/probe1.png</a><<a href="https://dl.dropbox.com/u/744216/probe1.png" target="_blank">https://dl.dropbox.com/u/744216/probe1.png</a>><br>
>>> <a href="https://dl.dropbox.com/u/**744216/probe2.png" target="_blank">https://dl.dropbox.com/u/**744216/probe2.png</a><<a href="https://dl.dropbox.com/u/744216/probe2.png" target="_blank">https://dl.dropbox.com/u/744216/probe2.png</a>><br>
>>><br>
>>> The values are wrong for points that are close to the boundary, and match<br>
>>> FieldView for points away from the boundary. I have also tried importing<br>
>>> the locations from a CSV file and using the Resample Dataset and get the<br>
>>> same values.<br>
>>><br>
>>> Can anyone shed light on why this is happening?<br>
><br>
<br>
</div></div></blockquote></div><br></div></div>