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 <[email protected]>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 <[email protected]> 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, [email protected] 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 < >> [email protected]>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? >> > >> >> >
_______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
