[vtkusers] algorithm performance

Sat Aug 3 14:25:14 EDT 2013

That functionality was just a convenience. Apparently it s gone. I'll have
to change the documentation.

On Sat, Aug 3, 2013 at 10:31 AM, Jeff Lee <jlee1549 at gmail.com> wrote:

> The only real difference between vtkCutter and that and vtkContourFilter
> is that Cutter computes the scalar field from the implicit function
> internally.  Not clear what the benefit is to have vtkCutter cut with a
> supplied scalar field when you already have vtkContourFilter...
>
>
> On Sat, Aug 3, 2013 at 10:11 AM, Gerrick Bivins <
> Gerrick.Bivins at halliburton.com> wrote:
>
>> 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
>>
>
>

-- 
Unpaid intern in BillsBasement at noware dot com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20130803/10f30a8b/attachment.htm>