[vtkusers] algorithm performance

Fri Aug 2 17:06:05 EDT 2013

I mean point scalar data array reperesenting the evaluation of the implicit
function f(xyz) at every node.

On Fri, Aug 2, 2013 at 5:02 PM, Gerrick Bivins <
Gerrick.Bivins at halliburton.com> wrote:

>  I think part of my confusion was “point data scalars”.****
>
> I initially read that as Scalars of vtkPointData but now I think you are
> meaning scalar data arrays that represent grid node coordinates.****
>
> Is that correct?****
>
> Gerrick****
>
> ** **
>
> *From:* Bill Lorensen [mailto:bill.lorensen at gmail.com]
> *Sent:* Friday, August 02, 2013 3:34 PM
> *To:* Jeff Lee
>
> *Cc:* Gerrick Bivins; vtkusers at vtk.org
> *Subject:* Re: [vtkusers] algorithm performance****
>
> ** **
>
> You can also compute the scalar data once and use that for cutting. You
> would need to generate the point data scalars programmaticly. I'm not sure
> there is a filter to do that.****
>
> ** **
>
> On Fri, Aug 2, 2013 at 4:19 PM, Jeff Lee <jlee1549 at gmail.com> wrote:****
>
> The cutter just evaluates the implicit function at every point in the
> input dataset, then contours that scalar field at the requested value
> (usually 0).  It is equivalent to generating your own point scalar field of
> the implicit function on the dataset and running it through a
> contourfilter, and ScalarTreeOn should produce the speedup of subsequent
> contour values assuming you are just changing the contour value.  For
> multiple cuts of the same function you would set multiple values in the
> filter, that would get you the multiple parallel slice case.  The scalar
> tree won't help if you are changing the implicit function (i.e. the scalar
> field), but extracting different contour values for a single field should
> show improvement.  The contour values would be the offset from the zero
> contour, so values of 0.0, .1, .2, etc.. would generate multiple planes
> including the original implicit definition.****
>
> ** **
>
> On Fri, Aug 2, 2013 at 4:03 PM, Bill Lorensen <bill.lorensen at gmail.com>
> wrote:****
>
> I'll try to find an example that does not use a cut function, but uses the
> scalar point data. I know I did this years ago when we first wrote
> vtkCutter and vtkClipPolyData.****
>
> You should be able to compute point data scalars for your dataset and use
> those scalars for cutting rtaher than a cut function.****
>
> At least that is how it used to work.****
>
> ** **
>
> On Fri, Aug 2, 2013 at 3:44 PM, Gerrick Bivins <
> Gerrick.Bivins at halliburton.com> wrote:****
>
> Bill,Jeff,****
>
> Currently, the slices will be orthogonal slices, parallel to the Cartesian
> axes (x,y,z).****
>
> Next request will be multiple arbitrarily oriented slices but probably
> parallel to each other (same normal).****
>
>  ****
>
> Still absorbing this. It’s not quite clear how I’d generate a planar slice
> using vtkCutter from the scalar data. ****
>
> Can either of you point me to some example code? ****
>
> Gerrick****
>
>  ****
>
> *From:* Jeff Lee [mailto:jlee1549 at gmail.com]
> *Sent:* Friday, August 02, 2013 12:01 PM
> *To:* Bill Lorensen
> *Cc:* Gerrick Bivins; vtkusers at vtk.org****
>
>
> *Subject:* Re: [vtkusers] algorithm performance****
>
>  ****
>
> IIRC the unstructured grid algorithm doesn't use a cell locator to find
> candidate cells, it runs over all cells and checks the scalar range of the
> cell and then contours it if the range is satisfied.  Its faster than
> blindly contouring every cell but not as good as it could be.  A better
> approach would be to use a scalar tree (where the function value is the
> scalar) and use that to locate candidate cells.  It will be expensive to
> build the tree the first time, but subsequent contours of the same function
> will typically be much faster, as the candidate cells have been sorted in
> bins by range in the scalar tree.  You would have to modify the algorithm a
> bit to do this, but i've had success with that approach in the past...****
>
>  ****
>
> On Fri, Aug 2, 2013 at 11:46 AM, Bill Lorensen <bill.lorensen at gmail.com>
> wrote:****
>
> Are the slice planes parallel to each other, or are they arbitrarily
> oriented?****
>
> If they are parallel, then you could compute point data scalars once and
> leave out the implicit function. Then Cutter will use the scalar data for
> cutting. This would avoid recomputing the scalar field for each slice.****
>
>  ****
>
>  ****
>
> On Fri, Aug 2, 2013 at 11:31 AM, Gerrick Bivins <
> Gerrick.Bivins at halliburton.com> wrote:****
>
> Hi Bill,****
>
> We are building release. Our grids are large at least 10’s – 100’s of
> thousands of cells.****
>
> I’m seeing the behavior in a Paraview  install as well,****
>
> with auto-apply on. Trying to move the slice plane through ****
>
> the dataset becomes less and less interactive as the dataset cell count
> increases.****
>
> So I was hoping there were some ways to speed this up.****
>
> Any other suggestions?****
>
> Gerrick****
>
>  ****
>
> *From:* Bill Lorensen [mailto:bill.lorensen at gmail.com]
> *Sent:* Friday, August 02, 2013 10:18 AM
> *To:* Gerrick Bivins
> *Cc:* vtkusers at vtk.org
> *Subject:* Re: [vtkusers] algorithm performance****
>
>  ****
>
> Also be sure you build VTK and your app Release and not Debug.****
>
>  ****
>
>  ****
>
> On Fri, Aug 2, 2013 at 11:08 AM, Gerrick Bivins <
> Gerrick.Bivins at halliburton.com> wrote:****
>
> Hi All,****
>
> I’m looking for suggestions on how to speed up an algorithm on large
> unstructured grids, like vtkCutter.****
>
> I thought I could build an octree (or similar structure) from the input
>  and execute the vtkCutter on the octree****
>
> but it’s not obvious to me how to do it. Is something like this possible?*
> ***
>
> How can I improve the speed of the algorithm? Performance seems to go down
> as cell count grows.****
>
> Gerrick****
>
>  ****
>  ------------------------------
>
> This e-mail, including any attached files, may contain confidential and
> privileged information for the sole use of the intended recipient. Any
> review, use, distribution, or disclosure by others is strictly prohibited.
> If you are not the intended recipient (or authorized to receive information
> for the intended recipient), please contact the sender by reply e-mail and
> delete all copies of this message.****
>
>
> _______________________________________________
> 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 VTK FAQ at:
> http://www.vtk.org/Wiki/VTK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.vtk.org/mailman/listinfo/vtkusers****
>
>
>
> ****
>
>  ****
>
> --
> Unpaid intern in BillsBasement at noware dot com****
>
>
>
>
> --
> Unpaid intern in BillsBasement at noware dot com****
>
>
> _______________________________________________
> 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 VTK FAQ at:
> http://www.vtk.org/Wiki/VTK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.vtk.org/mailman/listinfo/vtkusers****
>
>  ****
>
>
>
>
> --
> Unpaid intern in BillsBasement at noware dot com****
>
> ** **
>
>
>
>
> --
> Unpaid intern in BillsBasement at noware dot com****
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20130802/3d981462/attachment.htm>