Re: [Libmesh-devel] Loop subdivision surface elements

[David K. <dkn...@se...>]

I'd definitely be enthusiastic about getting support for shells in 
libMesh as well.

David


On 02/21/2014 11:20 AM, Paul T. Bauman wrote:
> Others may also be interested in this, but I have a keen interest. I'd 
> be happy to look at the patch, but, even better, would be for you to 
> open a pull request on GitHub (https://github.com/libMesh/libmesh) so 
> that, if we decide to integrate the patch, we have a commit history of 
> your development since it sounds like it's not a small patch.
>
> Best,
>
> Paul
>
>
> On Fri, Feb 21, 2014 at 8:53 AM, Roman Vetter <vet...@et... 
> <mailto:vet...@et...>> wrote:
>
>     Dear libMesh devs,
>
>     the roots of the finite element method lie in structural analysis and
>     the need to solve elasticity problems. Thin shells with a
>     stretching and
>     a bending rigidity are an extremely important special case. The
>     bending
>     term requires C1 finite elements which have been hard to construct for
>     arbitrary surface topologies until the subdivision surface paradigm
>     found its way to the FEM a few years ago (Int. J. Numer. Meth. Engng.
>     47, 2039-2072 (2000), more than 300 citations!). Ever since,
>     subdivision
>     surfaces are the way to go in thin shell finite element analysis,
>     as they
>
>     1) require only the three nodal displacement dofs, no rotational or
>     other auxiliary dofs,
>     2) require only one Gauss point per element (very efficient), although
>     more still work of course,
>     3) greatly simplify the implementation of thin shells with arbitrary
>     topology.
>
>     Still, they have not made it into most finite element packages,
>     perhaps
>     because they somewhat deviate from conventional FE principles:
>
>     a) the shape functions don't interpolate the mesh nodes, instead they
>     approximate them,
>     b) the solution on an element is determined not only by the nodal
>     solutions of its nodes, but also of nodal solutions at the
>     neighboring nodes
>     c) the number of shape functions per element depends on the mesh
>     connectivity,
>     d) the conventional h-refinement and p-refinement techniques can't be
>     applied
>     e) they require special treatment of boundaries and constraints.
>
>     I have prepared a patch that adds the most popular, versatile and
>     widely-used type of subdivision surface elements to libMesh: Loop
>     subdivision surface elements. Everything is readily Doxygen-commented
>     like all of libMesh. I've also prepared a new example
>     (miscellaneous_ex11) showing how to use the new element on a
>     loaded thin
>     elastic plate.
>
>     This is a joint effort initiated by Norbert Stoop in 2008. The related
>     discussions can be looked up at:
>     http://sourceforge.net/mailarchive/message.php?msg_id=20778890
>     http://sourceforge.net/mailarchive/message.php?msg_id=20808509
>
>     Why didn't I attach the patch already? I'd first like to know if
>     you're
>     interested at all. Why wouldn't you, you're asking? Bear in mind the
>     unconventional nature of subdivision surface finite elements. (b)
>     requires a more general treatment of the number of shape functions in
>     DofMap, as it is no longer constant. (c) requires a new integer stored
>     in each Node instance, holding the node valence. (d) means some of the
>     nice features of libMesh like AMR won't work with the new element. (e)
>     means that libMesh's built-in boundary and constraint handling won't
>     work with the new element. Furthermore the new element supports
>     only 2D
>     triangular meshes in 3D space, so it is a far cry from being as
>     general
>     as other elements implemented in libMesh.
>
>     Why would you be interested despite all this? First of all,
>     subdivision
>     surfaces seem to be the future of two-dimensional C1 elements. They
>     would give libMesh an advantage over other FEM packages. Moreover,
>     recent advances in finite element research suggest that more new
>     elements of this general kind (isogeometric analysis) are on the way.
>     Some of them similarly generalize the way we traditionally think about
>     element shape functions and even work with less than one quadrature
>     point per element [sic!].
>
>     This extension of libMesh adds five new source code files and modifies
>     22 more (mostly small additions like enums etc.). I've tried to
>     keep the
>     patch minimal. It has been in successful operation for a few years now
>     at our labs, and I think it's about time it's committed to the
>     official
>     libMesh repository. It would make a great added value to libMesh
>     for all
>     those who use it for thin shell analysis (and I know that there are a
>     few of them around). I'm happy to send you the patch and further
>     explanations on it if you're willing to give it a closer look.
>
>     Best regards,
>     Roman
>
>     ------------------------------------------------------------------------------
>     Managing the Performance of Cloud-Based Applications
>     Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
>     Read the Whitepaper.
>     http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
>     _______________________________________________
>     Libmesh-devel mailing list
>     Lib...@li...
>     <mailto:Lib...@li...>
>     https://lists.sourceforge.net/lists/listinfo/libmesh-devel
>
>
>
>
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Libmesh-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmesh-devel