This bounced the first time,<div>W<br><br><div class="gmail_quote">2011/4/2 Will Schroeder <span dir="ltr"><<a href="mailto:will.schroeder@kitware.com">will.schroeder@kitware.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

Hi Andreas-<div><br></div><div>Thank you very much for your insights. Let me try to address your questions in the following.</div><div><br></div><div>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.</div>


<div><br></div><div>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.</div><div><br></div><div>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.</div>


<div><br></div><div>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.</div>


<div><br></div><div>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.</div>


<div><br></div><div>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.</div>


<div><br></div><div><font color="#888888">W<br><br></font><div class="gmail_quote"><div><div></div><div class="h5">2011/3/23 Andreas Buykx <span dir="ltr"><<a href="mailto:A.Buykx@tnodiana.com" target="_blank">A.Buykx@tnodiana.com</a>></span><br>

</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div></div><div class="h5">






<div lang="NL" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span lang="EN-US">Hi all,</span></p>
<p class="MsoNormal"><span lang="EN-US"> </span></p>
<p class="MsoNormal"><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></p>
<p class="MsoNormal"><span lang="EN-US"> </span></p>
<p class="MsoNormal"><span lang="EN-US">Regarding the generic adaptor framework I have the following questions:</span></p>
<p><span lang="EN-US"><span>1.<span style="font:7.0pt "Times New Roman"">      
</span></span></span><span lang="EN-US">How mature is the framework, viz. how many projects/products have actually implemented the generic adaptor framework?</span></p>
<p><span lang="EN-US"><span>2.<span style="font:7.0pt "Times New Roman"">      
</span></span></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></p>
<p><span lang="EN-US"><span>3.<span style="font:7.0pt "Times New Roman"">      
</span></span></span><span lang="EN-US">Are there example implementations other than the bridge example from the VTK code base?</span></p>
<p class="MsoNormal"><span lang="EN-US"> </span></p>
<p class="MsoNormal" style="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></p>
<p style="margin-left:38.25pt">
<span lang="EN-US" style="font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman"">        
</span></span></span><span lang="EN-US">vtkCellType – trivial – add cell type id</span></p>
<p style="margin-left:38.25pt">
<span lang="EN-US" style="font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman"">        
</span></span></span><span lang="EN-US">vtkGenericCell – trivial – add case statement for cell instantiation</span></p>
<p style="margin-left:38.25pt">
<span lang="EN-US" style="font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman"">        
</span></span></span><span lang="EN-US">vtkUnstructuredGrid – trivial – add case statement for GetCell()</span></p>
<p style="margin-left:38.25pt">
<span lang="EN-US" style="font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman"">        
</span></span></span><span lang="EN-US">vtkBoxClipDataSet – almost trivial – add fall-through case statement for appropriate shape</span></p>
<p style="margin-left:38.25pt">
<span lang="EN-US" style="font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman"">        
</span></span></span><span lang="EN-US">vtkCutter – trivial – add cellTypeDimensions entry.  Only for non 3D cell types</span></p>
<p style="margin-left:38.25pt">
<span lang="EN-US" style="font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman"">        
</span></span></span><span lang="EN-US">vtkDataSetSurfaceFilter – nontrivial extension to UnstructuredGridExecute, but probably not needed if the default case performs sufficiently fast</span></p>
<p style="margin-left:38.25pt">
<span lang="EN-US" style="font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman"">        
</span></span></span><span lang="EN-US">vtkGeometryFilter – almost trivial - add fall-through case statement for appropriate shape(?)</span></p>
<p style="margin-left:38.25pt">
<span lang="EN-US" style="font-family:Symbol"><span>·<span style="font:7.0pt "Times New Roman"">        
</span></span></span><span lang="EN-US">vtkUnstructuredGridGeometryFilter – nontrivial addition to RequestData, except if fall-through case is appropriate.</span></p>
<p class="MsoNormal"><span lang="EN-US"> </span></p>
<p class="MsoNormal"><span lang="EN-US">Regarding extending the existing VTK cell collection my questions are:</span></p>
<p style="margin-left:38.25pt">
<span lang="EN-US"><span>1.<span style="font:7.0pt "Times New Roman"">      
</span></span></span><span lang="EN-US">Is the above analysis of impact to VTK code correct/complete?</span></p>
<p style="margin-left:38.25pt">
<span lang="EN-US"><span>2.<span style="font:7.0pt "Times New Roman"">      
</span></span></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></p>
<p style="margin-left:38.25pt">
<span lang="EN-US"><span>3.<span style="font:7.0pt "Times New Roman"">      
</span></span></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></p>
<p style="margin-left:38.25pt">
<span lang="EN-US"><span>4.<span style="font:7.0pt "Times New Roman"">      
</span></span></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></p>
<p class="MsoNormal"><span lang="EN-US"> </span></p>
<p class="MsoNormal"><span lang="EN-US">Are there other aspects that I should take into account when deciding which direction to take?</span></p>
<p class="MsoNormal"><span lang="EN-US">Are there other options besides the two outlined above?</span></p>
<p class="MsoNormal"><span lang="EN-US"> </span></p>
<p class="MsoNormal"><span lang="EN-US">Thanks a lot for your help.</span></p>
<p class="MsoNormal"><span lang="EN-US"> </span></p>
<p class="MsoNormal"><span lang="EN-US">Andreas Buykx</span></p>
<p class="MsoNormal"><span lang="EN-US"> </span></p>
<p class="MsoNormal" style="text-autospace:none"><b><span lang="EN-US" style="font-size:10.0pt;color:black">Andreas Buykx</span></b></p>
<p class="MsoNormal" style="text-autospace:none"><span lang="EN-US" style="font-size:10.0pt;color:black">Senior Software Engineer</span></p>
<p class="MsoNormal" style="text-autospace:none"><span lang="EN-US" style="font-size:10.0pt;color:black"> </span></p>
<p class="MsoNormal" style="text-autospace:none"><b><span lang="EN-US" style="font-size:11.5pt;color:#CB2027">TNO DIANA BV
</span></b><span lang="EN-US" style="font-size:11.5pt;color:#CB2027"></span></p>
<p class="MsoNormal" style="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></p>
<p class="MsoNormal" style="text-autospace:none"><span lang="EN-US" style="font-size:8.0pt;color:black"> </span></p>
<p class="MsoNormal" style="text-autospace:none"><span lang="EN-US" style="font-size:9.0pt;color:black">Delftechpark 19a, 2628 XJ, Delft, The Netherlands
</span></p>
<p class="MsoNormal" style="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></p>
<p class="MsoNormal" style="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 lang="EN-US"></span></span></i></b></p>
<p class="MsoNormal" style="text-autospace:none"><b><i><span lang="EN-US" style="font-size:9.0pt"> </span></i></b></p>
<p class="MsoNormal"><b><i><span lang="EN-US" style="font-size:9.0pt">…be green keep it on screen</span></i></b><span lang="EN-US"></span></p>
<p class="MsoNormal"><span lang="EN-US"> </span></p>
</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 <a href="http://tnodiana.com/content/Disclaimer" target="_blank">http://tnodiana.com/content/Disclaimer</a><br>
____________________________________________________________</font></div>

<br></div></div><div class="im">_______________________________________________<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>
<br></div></blockquote></div><div class="im"><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<br>
</div></div>
</blockquote></div><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<br>
</div>