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

Mon Apr 4 07:04:44 EDT 2011

The numbering is irrelevant. The main thing is that you have a continuous
parametric domain (r,s,t) in the canonical basis function space. This is
important during tessellation. THere's probably also implicit assumptions on
the topology of the elements (triangular vs rectangular).
W

On Mon, Apr 4, 2011 at 7:01 AM, Andreas Buykx <A.Buykx at tnodiana.com> wrote:

>  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>
>
> 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
>  ____________________________________________________________
> 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
> ____________________________________________________________
>

-- 
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/20110404/4eda8aea/attachment.html>