[vtk-developers] Generic adaptor framework vs. custom vtkCell types

Sun Apr 3 10:37:11 EDT 2011

This bounced the first time,
W

2011/4/2 Will Schroeder <will.schroeder at kitware.com>

> Hi Andreas-
>
> Thank you very much for your insights. Let me try to address your questions
> in the following.
>
> 1. The adaptor framework is relatively young in that we've not pushed on it
> very hard, and it has not been used in a lot of projects (as least that I
> know about).. However the good news is that in the last couple of months
> we've seen a couple of projects emerge so that we are now starting to work
> on it again (and others such as yourself have been making some queries). So
> I think there is growing energy to improve what's there. Like much of VTK,
> the first implementations are more about proof of concept than performance,
> so I'm pretty confident that we can see significant improvements once we put
> out minds to it.
>
> 2. As I said, I expect significant improvements. However, because of the
> nature of the abstraction it wouldn't surprise me if some performance
> penalty remains.
>
> 3. We have implementations that we are working on for some current
> customers, I don't think that we give them out just yet, but you're right
> the VTK example that's there is really confusing so we need to do better.
>
> As far as adding new cell types, adding a new cell to VTK is a real pain in
> the neck. Ensuring that the basis functions are correct, tessellations are
> done right, adding tests, etc. is tough which is why the generic framework
> was created to some extent. The idea was to try and centralize a lot of the
> basic functionality into the adaptor framework, and enable folks with their
> own basis functions to "plug-in" into VTK with a reduced amount of work. Of
> course as I'm sure you noticed, the generic cells are not limited in the
> number of filters that can operate on them, although this could probably be
> expanded with some work.
>
> Yes we have been adding new cells over the years with intentions to do a
> few more. The VTK_HIGHER_ORDER_... and VTK_PARAMETRIC_ I'm pretty sure are
> leftovers from some experiments to add NURBS and some other fancy cell
> types.
>
> The only other option which might be possible (and I haven't thought too
> hard about this) would be to extend vtkUnstructuredGrid so that it could
> support user-defined cell types, which would enable you to create your won
> library of cells. But this would take some serious work. If possible I'd
> like to get the adaptor framework right before we go down another path,
> largely because we are seeing a lot of emerging interest in it.
>
> W
>
> 2011/3/23 Andreas Buykx <A.Buykx at tnodiana.com>
>
>>  Hi all,
>>
>>
>>
>> We are studying the advantages and drawbacks of various options for
>> visualizing our finite element data with VTK.  Our elements map for a large
>> part to the existing VTK cells, but we have roughly 20-30 element types
>> (higher order elements and elements that model an interface between two
>> cells) that do not map to existing cell types. We expect that in the future
>> our library of elements will grow, requiring an approach that minimizes the
>> effort needed to implement new elements/cells. The two alternatives that we
>> are currently considering are implementing the VTK generic framework vs.
>> adding custom cells to VTK by deriving from vtkCell, vtkNonlinearCell, etc.
>>
>>
>>
>> Regarding the generic adaptor framework I have the following questions:
>>
>> 1.       How mature is the framework, viz. how many projects/products
>> have actually implemented the generic adaptor framework?
>>
>> 2.       From some experimentation it seems that walking over the cells
>> of a grid does not scale to 1M cells or more, and applying the provided
>> generic filtering algorithms also demonstrate a performance degradation by a
>> factor 2-3. Is this observation correct? Is there any work going on to
>> improve this?
>>
>> 3.       Are there example implementations other than the bridge example
>> from the VTK code base?
>>
>>
>>
>> Regarding extending the existing VTK cell collection I have investigated
>> the current 5.9 VTK code. It seems to me that there are several locations
>> where adding new cells requires significant patching of VTK code in the
>> Graphics and Filtering areas:
>>
>> ·         vtkCellType – trivial – add cell type id
>>
>> ·         vtkGenericCell – trivial – add case statement for cell
>> instantiation
>>
>> ·         vtkUnstructuredGrid – trivial – add case statement for
>> GetCell()
>>
>> ·         vtkBoxClipDataSet – almost trivial – add fall-through case
>> statement for appropriate shape
>>
>> ·         vtkCutter – trivial – add cellTypeDimensions entry.  Only for
>> non 3D cell types
>>
>> ·         vtkDataSetSurfaceFilter – nontrivial extension to
>> UnstructuredGridExecute, but probably not needed if the default case
>> performs sufficiently fast
>>
>> ·         vtkGeometryFilter – almost trivial - add fall-through case
>> statement for appropriate shape(?)
>>
>> ·         vtkUnstructuredGridGeometryFilter – nontrivial addition to
>> RequestData, except if fall-through case is appropriate.
>>
>>
>>
>> Regarding extending the existing VTK cell collection my questions are:
>>
>> 1.       Is the above analysis of impact to VTK code correct/complete?
>>
>> 2.       We are very reluctant to go into this much patching. Are there
>> other approaches that have less impact to existing VTK code?
>>
>> 3.       What are the experiences with adding new cell types as outlined
>> above? Has it been done before at all?
>>
>> 4.       It seems that there are several cell type ids that are entered
>> in the VTKCellType enumeration that are not supported by the code, esp. the
>> VTK_HIGHER_ORDER_... and VTK_PARAMETRIC_... entries. What is the intent of
>> those entries?
>>
>>
>>
>> Are there other aspects that I should take into account when deciding
>> which direction to take?
>>
>> Are there other options besides the two outlined above?
>>
>>
>>
>> Thanks a lot for your help.
>>
>>
>>
>> Andreas Buykx
>>
>>
>>
>> *Andreas Buykx*
>>
>> Senior Software Engineer
>>
>>
>>
>> *TNO DIANA BV *
>>
>> *Software Developers and Analysis Consultants for Civil and Geotechnical
>> Engineering *
>>
>>
>>
>> Delftechpark 19a, 2628 XJ, Delft, The Netherlands
>>
>> Tel: +31 88 34262 15 (Direct) │ Tel: +31 88 34262 00 (Switchboard) │ +31
>> 88 34262 99 (Fax)
>>
>> http://tnodiana.com* *
>>
>> * *
>>
>> *…be green keep it on screen*
>>
>>
>>  ____________________________________________________________
>> TNO DIANA BV is a limited liability company registered in the trade
>> register of the Chamber of Commerce as TNO DIANA BV with registered number
>> 27252655.
>> ____________________________________________________________
>> This e-mail and its contents are subject to the DISCLAIMER at
>> http://tnodiana.com/content/Disclaimer
>> ____________________________________________________________
>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.vtk.org/mailman/listinfo/vtk-developers
>>
>>
>>
>
>
> --
> William J. Schroeder, PhD
> Kitware, Inc.
> 28 Corporate Drive
> Clifton Park, NY 12065
> will.schroeder at kitware.com
> http://www.kitware.com
> (518) 881-4902
>


-- 
William J. Schroeder, PhD
Kitware, Inc.
28 Corporate Drive
Clifton Park, NY 12065
will.schroeder at kitware.com
http://www.kitware.com
(518) 881-4902
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20110403/5e5bfca0/attachment.html>