[vtkusers] algorithm performance

Sat Aug 3 10:11:22 EDT 2013

Ok. When I looked at the source for vtkcutter I didn't see a code path that allowed execution without specifying an implicit function. Is this what you mean?

Sent from my Android phone using TouchDown (www.nitrodesk.com)

________________________________
From: Bill Lorensen
Sent: Saturday, August 03, 2013 2:00:06 PM
To: Jeff Lee
Cc: Gerrick Bivins; vtkusers at vtk.org
Subject: Re: [vtkusers] algorithm performance

I just checked vtkCutter. I don't think it will use supplied scalars. Used to work. I think it is a bug I'll need to look into.

On Fri, Aug 2, 2013 at 5:16 PM, Bill Lorensen <bill.lorensen at gmail.com<mailto:bill.lorensen at gmail.com>> wrote:
Exactly. ANd I'm saying you can compute that scaalr data ONCE outside of vtkCutter and possibly save some time. If you specify a CutFunction vtkCutter will recompute the scalar data every time you change the plane. If you provide point data scalars (of the plane), you can just change the isovalue to "move the plane".

On Fri, Aug 2, 2013 at 5:06 PM, Jeff Lee <jlee1549 at gmail.com<mailto:jlee1549 at gmail.com>> wrote:
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<mailto: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<mailto:bill.lorensen at gmail.com>]
Sent: Friday, August 02, 2013 3:34 PM
To: Jeff Lee

Cc: Gerrick Bivins; vtkusers at vtk.org<mailto: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<mailto: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<mailto: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<mailto: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<mailto:jlee1549 at gmail.com>]
Sent: Friday, August 02, 2013 12:01 PM
To: Bill Lorensen
Cc: Gerrick Bivins; vtkusers at vtk.org<mailto: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<mailto: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<mailto: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<mailto:bill.lorensen at gmail.com>]
Sent: Friday, August 02, 2013 10:18 AM
To: Gerrick Bivins
Cc: vtkusers at vtk.org<mailto: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<mailto: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<http://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<http://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

--
Unpaid intern in BillsBasement at noware dot com

--
Unpaid intern in BillsBasement at noware dot com