[vtk-developers] New nonlinear celltypes

[David C. Thompson]

Soeren,

    It is great to see more people interested in higher order elements!
I agree with Will that it would be nice to see your new elements in VTK
if you are really willing to do all the work required to get them there.
Also, it would be great to hear specific problems you have with the
generic dataset representation. I'll try and address some of your
comments below.

	David
--
David Thompson, MS 9152                (925)294-2537
Sandia National Laboratories           dcthomp at sandia.gov
PO Box 969, Livermore, CA 94551-0969

On Fri, 2005-12-16 at 06:24, Soeren Gebbert wrote:
> Will Schroeder wrote:
> > ... One of the ideas 
> > behind this is that no new cells would be introduced into VTK, rather 
> > an adaptor to an external "library" of elements would be created. Part 
> > of the rational was to avoid adding lots of new cells to VTK, because 
> > the potential list is endless and requires modifying filters, reader, 
> > writers, file formats, etc. for each new cell. ...
> 
> When i started to implement these cells, i was thinking about to use 
> only the framework. But after a while of planing and thinking, i decided 
> to extend VTK because:
> * we are using all kind of celltypes the VTK-unstructured-gid are 
> provides (except the pyramid) and the new cell types together
The bridge dataset is provided for testing and also as a starting point
so that you need not implement adaptors for linear cell types.

> * It was very important for us to provide data integrity while the 
> analyses/visualisation process, that mean, we need to know what kind of 
> cells are used and
>    in which kind of cells we can convert (3D cells to 2D faces and so on 
> ...)
I am not sure I understand this; how does the generic dataset not
provide this information? vtkGenericAdaptorCell provides cell type and
dimensionality. If you are referring to the results of tessellation, the
vtkGenericDataSetTessellator has a KeepCellIds attribute that will
generate a new "cell IDs" attribute so that you can look up which higher
order element generated a particular linear one.

> * we are working with large datasets (many 10.000 cells), the time 
> consumption to tessellate such huge datasets with 3D cells is enormus
> * We need to visualize these data as fast as possible for interactive 
> analyses (with Qt3 gui),
> We have worked very hard to make this process fast. If you have a specific case that takes a long time, is it something you could provide more information about so that we can find out what is impacting the performance?

>    and i thought the generic aproach is not fast enough for this 
> (contouring ...) and dont provide all the functionality we need. (maybe 
> im wrong!)
For contouring the generic approach introduces some additional overhead
for higher order elements because the tessellation that occurs requires
coincident points to be merged. However, for the number of cells you are
dealing with, the generic approach should not be significantly slower
than vtkUnstructuredGrid unless you put tight tolerances on the
tessellation algorithm so that many linear elements are required to
approximate a single higher order cell. If you did that it would be
slow, but it would also be unfair to compare it to a contour generated
on a vtkUnstructuredGrid because vtkCell performs a fixed subdivision of
each cell before contouring rather than an adaptive one.

> * We need more filters for the new cells than the generic aproach provides.
>     And there are many filters for unstructured grids and datasets in 
> VTK we are happily using.
If anything, this is the Achilles heel of the generic dataset API right
now. Until we have the resources to make more filters available, you can
certainly use the dataset tessellator to create an approximation of the
higher order elements and use any VTK filter on that approximation.