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

Mon Apr 4 07:01:34 EDT 2011

Thanks for your replies.

The example implementation of the generic adaptor framework bridges a vtkDataSet. As a consequence it does not indicate whether there are VTK conventions/assumptions about the data set that have to be guaranteed by the bridge implementation. For example: the elements in our finite-element application have a different numbering scheme than corresponding VTK cell types. If we would build bridge classes implementing vtkGenericAdaptorCell and vtkGenericPointIterator etc., would these have to renumber the nodes to match VTK numbering conventions, or are the generic algorithm versions designed such that they are indifferent to the order of nodes/faces? Are there other conventions in vtk data sets and algorithms that must be satisfied by the bridge implementation of our element mesh?

Kind regards,
Andreas

From: Will Schroeder [mailto:will.schroeder at kitware.com]
Sent: Sunday, April 03, 2011 4:37 PM
To: Andreas Buykx
Cc: vtk-developers at vtk.org; Sebastien Jourdain
Subject: Re: [vtk-developers] Generic adaptor framework vs. custom vtkCell types

This bounced the first time,
W
2011/4/2 Will Schroeder <will.schroeder at kitware.com<mailto: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<mailto: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<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<http://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<mailto: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<mailto:will.schroeder at kitware.com>
http://www.kitware.com
(518) 881-4902
____________________________________________________________
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
____________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20110404/5b8029a8/attachment.html>