[vtkusers] algorithm performance

Bill Lorensen bill.lorensen at gmail.com
Sat Aug 3 10:00:06 EDT 2013


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>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> 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> 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****
>>>
>>
>>
>
>
> --
> 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/8068dfb4/attachment.htm>


More information about the vtkusers mailing list