<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
@page WordSection1
{size:8.5in 11.0in;
margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="NL" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US">Thanks for your replies. <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">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?<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Kind regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Andreas<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Will Schroeder [mailto:will.schroeder@kitware.com]
<br>
<b>Sent:</b> Sunday, April 03, 2011 4:37 PM<br>
<b>To:</b> Andreas Buykx<br>
<b>Cc:</b> vtk-developers@vtk.org; Sebastien Jourdain<br>
<b>Subject:</b> Re: [vtk-developers] Generic adaptor framework vs. custom vtkCell types<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">This bounced the first time,<o:p></o:p></p>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">W<o:p></o:p></p>
<div>
<p class="MsoNormal">2011/4/2 Will Schroeder <<a href="mailto:will.schroeder@kitware.com">will.schroeder@kitware.com</a>><o:p></o:p></p>
<p class="MsoNormal">Hi Andreas-<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Thank you very much for your insights. Let me try to address your questions in the following.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="color:#888888">W</span><o:p></o:p></p>
<div>
<div>
<div>
<p class="MsoNormal">2011/3/23 Andreas Buykx <<a href="mailto:A.Buykx@tnodiana.com" target="_blank">A.Buykx@tnodiana.com</a>><o:p></o:p></p>
</div>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US">Hi all,</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US">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.
</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US">Regarding the generic adaptor framework I have the following questions:</span><o:p></o:p></p>
<p><span lang="EN-US">1.</span><span lang="EN-US" style="font-size:7.0pt"> </span>
<span lang="EN-US">How mature is the framework, viz. how many projects/products have actually implemented the generic adaptor framework?</span><o:p></o:p></p>
<p><span lang="EN-US">2.</span><span lang="EN-US" style="font-size:7.0pt"> </span>
<span lang="EN-US">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?</span><o:p></o:p></p>
<p><span lang="EN-US">3.</span><span lang="EN-US" style="font-size:7.0pt"> </span>
<span lang="EN-US">Are there example implementations other than the bridge example from the VTK code base?</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:2.25pt">
<span lang="EN-US">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:</span><o:p></o:p></p>
<p style="margin-left:38.25pt"><span lang="EN-US" style="font-family:Symbol">·</span><span lang="EN-US" style="font-size:7.0pt">
</span><span lang="EN-US">vtkCellType – trivial – add cell type id</span><o:p></o:p></p>
<p style="margin-left:38.25pt"><span lang="EN-US" style="font-family:Symbol">·</span><span lang="EN-US" style="font-size:7.0pt">
</span><span lang="EN-US">vtkGenericCell – trivial – add case statement for cell instantiation</span><o:p></o:p></p>
<p style="margin-left:38.25pt"><span lang="EN-US" style="font-family:Symbol">·</span><span lang="EN-US" style="font-size:7.0pt">
</span><span lang="EN-US">vtkUnstructuredGrid – trivial – add case statement for GetCell()</span><o:p></o:p></p>
<p style="margin-left:38.25pt"><span lang="EN-US" style="font-family:Symbol">·</span><span lang="EN-US" style="font-size:7.0pt">
</span><span lang="EN-US">vtkBoxClipDataSet – almost trivial – add fall-through case statement for appropriate shape</span><o:p></o:p></p>
<p style="margin-left:38.25pt"><span lang="EN-US" style="font-family:Symbol">·</span><span lang="EN-US" style="font-size:7.0pt">
</span><span lang="EN-US">vtkCutter – trivial – add cellTypeDimensions entry. Only for non 3D cell types</span><o:p></o:p></p>
<p style="margin-left:38.25pt"><span lang="EN-US" style="font-family:Symbol">·</span><span lang="EN-US" style="font-size:7.0pt">
</span><span lang="EN-US">vtkDataSetSurfaceFilter – nontrivial extension to UnstructuredGridExecute, but probably not needed if the default case performs sufficiently fast</span><o:p></o:p></p>
<p style="margin-left:38.25pt"><span lang="EN-US" style="font-family:Symbol">·</span><span lang="EN-US" style="font-size:7.0pt">
</span><span lang="EN-US">vtkGeometryFilter – almost trivial - add fall-through case statement for appropriate shape(?)</span><o:p></o:p></p>
<p style="margin-left:38.25pt"><span lang="EN-US" style="font-family:Symbol">·</span><span lang="EN-US" style="font-size:7.0pt">
</span><span lang="EN-US">vtkUnstructuredGridGeometryFilter – nontrivial addition to RequestData, except if fall-through case is appropriate.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US">Regarding extending the existing VTK cell collection my questions are:</span><o:p></o:p></p>
<p style="margin-left:38.25pt"><span lang="EN-US">1.</span><span lang="EN-US" style="font-size:7.0pt">
</span><span lang="EN-US">Is the above analysis of impact to VTK code correct/complete?</span><o:p></o:p></p>
<p style="margin-left:38.25pt"><span lang="EN-US">2.</span><span lang="EN-US" style="font-size:7.0pt">
</span><span lang="EN-US">We are very reluctant to go into this much patching. Are there other approaches that have less impact to existing VTK code?</span><o:p></o:p></p>
<p style="margin-left:38.25pt"><span lang="EN-US">3.</span><span lang="EN-US" style="font-size:7.0pt">
</span><span lang="EN-US">What are the experiences with adding new cell types as outlined above? Has it been done before at all?
</span><o:p></o:p></p>
<p style="margin-left:38.25pt"><span lang="EN-US">4.</span><span lang="EN-US" style="font-size:7.0pt">
</span><span lang="EN-US">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?</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US">Are there other aspects that I should take into account when deciding which direction to take?</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US">Are there other options besides the two outlined above?</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US">Thanks a lot for your help.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US">Andreas Buykx</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;text-autospace:none">
<b><span lang="EN-US" style="font-size:10.0pt;color:black">Andreas Buykx</span></b><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;text-autospace:none">
<span lang="EN-US" style="font-size:10.0pt;color:black">Senior Software Engineer</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;text-autospace:none">
<span lang="EN-US" style="font-size:10.0pt;color:black"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;text-autospace:none">
<b><span lang="EN-US" style="font-size:11.5pt;color:#CB2027">TNO DIANA BV </span>
</b><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;text-autospace:none">
<i><span lang="EN-US" style="font-size:8.0pt;color:black">Software Developers and Analysis Consultants for Civil and Geotechnical Engineering
</span></i><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;text-autospace:none">
<span lang="EN-US" style="font-size:8.0pt;color:black"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;text-autospace:none">
<span lang="EN-US" style="font-size:9.0pt;color:black">Delftechpark 19a, 2628 XJ, Delft, The Netherlands
</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;text-autospace:none">
<span lang="EN-US" style="font-size:9.0pt;color:black">Tel: +31 88 34262 15 (Direct)
</span><span lang="EN-US" style="color:black">│ Tel: +31 88 34262 00 (Switchboard) │ +31 88 34262 99 (Fax)
</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;text-autospace:none">
<span style="font-size:9.0pt;color:black"><a href="http://tnodiana.com/" target="_blank"><span lang="EN-US">http://tnodiana.com</span></a></span><b><i><span style="font-size:9.0pt">
</span></i></b><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;text-autospace:none">
<b><i><span lang="EN-US" style="font-size:9.0pt"> </span></i></b><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><i><span lang="EN-US" style="font-size:9.0pt">…be green keep it on screen</span></i></b><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US"> </span><o:p></o:p></p>
</div>
<p class="MsoNormal"><span style="font-family:"Courier New"">____________________________________________________________<br>
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.<br>
____________________________________________________________<br>
This e-mail and its contents are subject to the DISCLAIMER at <a href="http://tnodiana.com/content/Disclaimer" target="_blank">
http://tnodiana.com/content/Disclaimer</a><br>
____________________________________________________________</span><o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">_______________________________________________<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">
http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://www.vtk.org/mailman/listinfo/vtk-developers" target="_blank">http://www.vtk.org/mailman/listinfo/vtk-developers</a><br>
<br>
<o:p></o:p></p>
</div>
</blockquote>
</div>
<div>
<p class="MsoNormal"><br>
<br clear="all">
<br>
-- <br>
William J. Schroeder, PhD<br>
Kitware, Inc.<br>
28 Corporate Drive<br>
Clifton Park, NY 12065<br>
<a href="mailto:will.schroeder@kitware.com" target="_blank">will.schroeder@kitware.com</a><br>
<a href="http://www.kitware.com" target="_blank">http://www.kitware.com</a><br>
(518) 881-4902<o:p></o:p></p>
</div>
</div>
</div>
<p class="MsoNormal"><br>
<br clear="all">
<br>
-- <br>
William J. Schroeder, PhD<br>
Kitware, Inc.<br>
28 Corporate Drive<br>
Clifton Park, NY 12065<br>
<a href="mailto:will.schroeder@kitware.com">will.schroeder@kitware.com</a><br>
<a href="http://www.kitware.com">http://www.kitware.com</a><br>
(518) 881-4902<o:p></o:p></p>
</div>
</div>
<font face="monospace">____________________________________________________________<br>
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.<br>
____________________________________________________________<br>
This e-mail and its contents are subject to the DISCLAIMER at http://tnodiana.com/content/Disclaimer<br>
____________________________________________________________</font></body>
</html>