libmesh-devel

[Libmesh-devel] Loop subdivision surface elements

[Roman V. <vet...@et...>]

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

Re: [Libmesh-devel] Loop subdivision surface elements

[Paul T. B. <ptb...@gm...>]

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...> 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...
> https://lists.sourceforge.net/lists/listinfo/libmesh-devel
>

Re: [Libmesh-devel] Loop subdivision surface elements

[Kirk, B. (JSC-EG311) <ben...@na...>]

Agreed!

 And if you're not comfortable generating the pull request I could help - if you send along the patch I can try and break it up into number of smaller changes on a new branch, and we can start discussion.

-Ben
On Feb 21, 2014, at 10:20 AM, Paul T. Bauman <ptb...@gm...> 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...> 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...
> 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

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

Re: [Libmesh-devel] Loop subdivision surface elements

[Derek G. <fri...@gm...>]

Another vote for shells - this would be super handy...

Derek


On Fri, Feb 21, 2014 at 9:55 AM, David Knezevic
<dkn...@se...>wrote:

>  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...> 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...
>> 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 lis...@li...://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
>
>

Re: [Libmesh-devel] Loop subdivision surface elements

[Roman V. <vet...@et...>]

>   And if you're not comfortable generating the pull request I could help - if you send along the patch I can try and break it up into number of smaller changes on a new branch, and we can start discussion.

I'm very new to git, and it's all still a bit confusing, so I think I'll 
gladly accept the help. :)

Here's the patch. You'll need to run ./bootstrap as I didn't include the 
autoconf/automake/libtool output.

A few more explanations on the code:

1. As already mentioned (also by Norbert), the solution on a given 
element depends on the 1-ring of that element (i.e., the direct neighbor 
elements). Obviously, boundary elements lack such neighbors. Therefore, 
subdivision meshes require special preparation, where an additional 
layer of elements is added along the mesh boundaries. These additional 
elements do not belong to the physical domain.

2. The added boundary elements are named "ghost" elements in the 
literature. I guess this name somewhat clashes with the "ghost" elements 
that lie on processor domain boundaries.

3. Any program using subdivision surface elements will need to operate 
only on non-ghost elements. To this end, a new element type TRI3SD is 
added, providing the is_ghost() member.

4. Nodes that have valence 6 are called "regular", otherwise they are 
"irregular". Elements are regular iff all their nodes are regular. 
Regular elements have exactly 12 shape functions (quartic box splines). 
Irregular elements, however, need special treatment.

5. Even though the subdivision surface shape functions are quartic, one 
Gauss point per element is perfectly sufficient. The traditional 
theoretical lower bound (predicting a minimum of 6 points for triangular 
elements with quartic shape fcts) doesn't apply due to the overlapping 
subdiv shape functions.

6. For efficiency, we internally reorder the nodes of TRI3SD elements in 
such a way that if the elements is irregular, the irregular vertex is 
always the first (see also 
http://sourceforge.net/mailarchive/message.php?msg_id=20808509) and only 
the first. Clearly, this means that only meshes with elements with at 
most one irregular vertex are supported. (The mesh preparator will 
properly complain otherwise.)

7. The custom DofMap originally mentioned by Norbert 
(http://sourceforge.net/mailarchive/message.php?msg_id=20778890) was 
avoided in the present implementation by generalizing the way DofMap 
computes the dof_indices.

8. Due to 1., boundary conditions are non-trivial to impose. Have a look 
at miscellaneous_ex11 or the original paper (Int. J. Numer. Meth. Engng. 
47, 2039-2072 (2000)) for one way to impose them. See Int. J. Numer. 
Meth. Eng. 61, 380–405 (2004) for an alternative constraint approach.

9. I don't know what happens if a user attempts to use AMR, libmesh's 
boundary functionality, or constraints on the subdivision surface 
elements. I simply haven't tried.

Feel free to ask more questions.

-Roman

Re: [Libmesh-devel] Loop subdivision surface elements

[Roy S. <roy...@ic...>]

On Mon, 24 Feb 2014, Roman Vetter wrote:

>>   And if you're not comfortable generating the pull request I could help - 
>> if you send along the patch I can try and break it up into number of 
>> smaller changes on a new branch, and we can start discussion.
>
> I'm very new to git, and it's all still a bit confusing, so I think I'll 
> gladly accept the help. :)

Since Ben's volunteered to set up the PR, I'll wait for that before
diving in to the code.

When I do dive into the code it will probably be as inline comments to
the PR, though; it would be helpful if you would make a github account
so you could join in on any discussion there.
---
Roy

Re: [Libmesh-devel] Loop subdivision surface elements

[Roman V. <vet...@et...>]

Has anyone had time to give it a look?

-Roman

Re: [Libmesh-devel] Loop subdivision surface elements

[Kirk, B. (JSC-EG311) <ben...@na...>]

Thanks Roman, I'm hoping to set up the PR today.  Could you tell me what version of libMesh you created this patch from? That'll help a lot.  It *almost* applies cleanly on 0.9.3, but there are a few failures:

$ patch -p1 < ~/Desktop/0001-Add-Loop-subdivision-surface-elements.patch --dry-run
patching file configure.ac
Hunk #1 FAILED at 303.
1 out of 1 hunk FAILED -- saving rejects to file configure.ac.rej
patching file examples/miscellaneous/miscellaneous_ex11/Makefile.am
patching file examples/miscellaneous/miscellaneous_ex11/miscellaneous_ex11.C
patching file examples/miscellaneous/miscellaneous_ex11/run.sh
patching file examples/miscellaneous/miscellaneous_ex11/square_mesh.off
patching file include/base/dof_map.h
Hunk #1 FAILED at 1057.
1 out of 1 hunk FAILED -- saving rejects to file include/base/dof_map.h.rej
patching file include/enums/enum_elem_type.h
patching file include/enums/enum_fe_family.h
patching file include/fe/fe.h
patching file include/fe/fe_map.h
patching file include/geom/face_tri3_sd.h
patching file include/geom/node.h
patching file include/include_HEADERS
patching file include/mesh/mesh_subdiv_support.h
patching file src/base/dof_map.C
Hunk #2 FAILED at 1661.
Hunk #3 FAILED at 1679.
Hunk #4 FAILED at 1715.
Hunk #5 succeeded at 1676 (offset -74 lines).
Hunk #6 succeeded at 1695 with fuzz 2 (offset -74 lines).
Hunk #7 FAILED at 1722.
Hunk #8 FAILED at 1748.
Hunk #9 FAILED at 1772.
Hunk #10 FAILED at 1851.
Hunk #11 succeeded at 1946 (offset -86 lines).
Hunk #12 succeeded at 1964 (offset -81 lines).
Hunk #13 succeeded at 2029 with fuzz 1 (offset -68 lines).
7 out of 13 hunks FAILED -- saving rejects to file src/base/dof_map.C.rej
patching file src/fe/fe.C
patching file src/fe/fe_abstract.C
patching file src/fe/fe_base.C
patching file src/fe/fe_boundary.C
patching file src/fe/fe_interface.C
patching file src/fe/fe_lagrange.C
patching file src/fe/fe_map.C
patching file src/fe/fe_subdiv_2D.C
patching file src/fe/fe_transformation_base.C
patching file src/fe/fe_type.C
patching file src/geom/elem.C
patching file src/geom/face_tri3_sd.C
patching file src/libmesh_SOURCES
patching file src/mesh/exodusII_io_helper.C
Hunk #1 succeeded at 1944 (offset -119 lines).
patching file src/mesh/mesh_subdiv_support.C
patching file src/mesh/vtk_io.C
patching file src/quadrature/quadrature_gauss_2D.C
patching file src/utils/string_to_enum.C





On Feb 24, 2014, at 9:37 AM, Roman Vetter <vet...@et...> wrote:

>>  And if you're not comfortable generating the pull request I could help - if you send along the patch I can try and break it up into number of smaller changes on a new branch, and we can start discussion.
> 
> I'm very new to git, and it's all still a bit confusing, so I think I'll gladly accept the help. :)
> 
> Here's the patch. You'll need to run ./bootstrap as I didn't include the autoconf/automake/libtool output.
> 
> A few more explanations on the code:
> 
> 1. As already mentioned (also by Norbert), the solution on a given element depends on the 1-ring of that element (i.e., the direct neighbor elements). Obviously, boundary elements lack such neighbors. Therefore, subdivision meshes require special preparation, where an additional layer of elements is added along the mesh boundaries. These additional elements do not belong to the physical domain.
> 
> 2. The added boundary elements are named "ghost" elements in the literature. I guess this name somewhat clashes with the "ghost" elements that lie on processor domain boundaries.
> 
> 3. Any program using subdivision surface elements will need to operate only on non-ghost elements. To this end, a new element type TRI3SD is added, providing the is_ghost() member.
> 
> 4. Nodes that have valence 6 are called "regular", otherwise they are "irregular". Elements are regular iff all their nodes are regular. Regular elements have exactly 12 shape functions (quartic box splines). Irregular elements, however, need special treatment.
> 
> 5. Even though the subdivision surface shape functions are quartic, one Gauss point per element is perfectly sufficient. The traditional theoretical lower bound (predicting a minimum of 6 points for triangular elements with quartic shape fcts) doesn't apply due to the overlapping subdiv shape functions.
> 
> 6. For efficiency, we internally reorder the nodes of TRI3SD elements in such a way that if the elements is irregular, the irregular vertex is always the first (see also http://sourceforge.net/mailarchive/message.php?msg_id=20808509) and only the first. Clearly, this means that only meshes with elements with at most one irregular vertex are supported. (The mesh preparator will properly complain otherwise.)
> 
> 7. The custom DofMap originally mentioned by Norbert (http://sourceforge.net/mailarchive/message.php?msg_id=20778890) was avoided in the present implementation by generalizing the way DofMap computes the dof_indices.
> 
> 8. Due to 1., boundary conditions are non-trivial to impose. Have a look at miscellaneous_ex11 or the original paper (Int. J. Numer. Meth. Engng. 47, 2039-2072 (2000)) for one way to impose them. See Int. J. Numer. Meth. Eng. 61, 380–405 (2004) for an alternative constraint approach.
> 
> 9. I don't know what happens if a user attempts to use AMR, libmesh's boundary functionality, or constraints on the subdivision surface elements. I simply haven't tried.
> 
> Feel free to ask more questions.
> 
> -Roman
> <0001-Add-Loop-subdivision-surface-elements.patch>------------------------------------------------------------------------------
> Flow-based real-time traffic analytics software. Cisco certified tool.
> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
> Customize your own dashboards, set traffic alerts and generate reports.
> Network behavioral analysis & security monitoring. All-in-one tool.
> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk_______________________________________________
> Libmesh-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmesh-devel

Re: [Libmesh-devel] Loop subdivision surface elements

[Roman V. <vet...@et...>]

Thank you, Ben. I've created the patch from the commit with short hash 
59fc67cf39.

-Roman


Am 2014-03-06 14:56 , schrieb Kirk, Benjamin (JSC-EG311):
> Thanks Roman, I'm hoping to set up the PR today.  Could you tell me what version of libMesh you created this patch from? That'll help a lot.

Re: [Libmesh-devel] Loop subdivision surface elements

[Kirk, B. (JSC-EG311) <ben...@na...>]

I've got this set up on https://github.com/libMesh/libmesh/tree/subdivision_surfaces

(subdivision_surfaces branch)

the new example, misc11, runs.  I applied the patch as-is and then needed to make some small tweaks to avoid duplicate symbols from template functions, these tend to show up on OSX when they can be hidden on linux.

Anyone (John?) want to help me rebase it against master?  mostly whitespace issues...

-Ben



On Mar 6, 2014, at 7:56 AM, Kirk, Benjamin (JSC-EG311) <ben...@na...> wrote:

> Thanks Roman, I'm hoping to set up the PR today.  Could you tell me what version of libMesh you created this patch from? That'll help a lot.  It *almost* applies cleanly on 0.9.3, but there are a few failures:
> 
> $ patch -p1 < ~/Desktop/0001-Add-Loop-subdivision-surface-elements.patch --dry-run
> patching file configure.ac
> Hunk #1 FAILED at 303.
> 1 out of 1 hunk FAILED -- saving rejects to file configure.ac.rej
> patching file examples/miscellaneous/miscellaneous_ex11/Makefile.am
> patching file examples/miscellaneous/miscellaneous_ex11/miscellaneous_ex11.C
> patching file examples/miscellaneous/miscellaneous_ex11/run.sh
> patching file examples/miscellaneous/miscellaneous_ex11/square_mesh.off
> patching file include/base/dof_map.h
> Hunk #1 FAILED at 1057.
> 1 out of 1 hunk FAILED -- saving rejects to file include/base/dof_map.h.rej
> patching file include/enums/enum_elem_type.h
> patching file include/enums/enum_fe_family.h
> patching file include/fe/fe.h
> patching file include/fe/fe_map.h
> patching file include/geom/face_tri3_sd.h
> patching file include/geom/node.h
> patching file include/include_HEADERS
> patching file include/mesh/mesh_subdiv_support.h
> patching file src/base/dof_map.C
> Hunk #2 FAILED at 1661.
> Hunk #3 FAILED at 1679.
> Hunk #4 FAILED at 1715.
> Hunk #5 succeeded at 1676 (offset -74 lines).
> Hunk #6 succeeded at 1695 with fuzz 2 (offset -74 lines).
> Hunk #7 FAILED at 1722.
> Hunk #8 FAILED at 1748.
> Hunk #9 FAILED at 1772.
> Hunk #10 FAILED at 1851.
> Hunk #11 succeeded at 1946 (offset -86 lines).
> Hunk #12 succeeded at 1964 (offset -81 lines).
> Hunk #13 succeeded at 2029 with fuzz 1 (offset -68 lines).
> 7 out of 13 hunks FAILED -- saving rejects to file src/base/dof_map.C.rej
> patching file src/fe/fe.C
> patching file src/fe/fe_abstract.C
> patching file src/fe/fe_base.C
> patching file src/fe/fe_boundary.C
> patching file src/fe/fe_interface.C
> patching file src/fe/fe_lagrange.C
> patching file src/fe/fe_map.C
> patching file src/fe/fe_subdiv_2D.C
> patching file src/fe/fe_transformation_base.C
> patching file src/fe/fe_type.C
> patching file src/geom/elem.C
> patching file src/geom/face_tri3_sd.C
> patching file src/libmesh_SOURCES
> patching file src/mesh/exodusII_io_helper.C
> Hunk #1 succeeded at 1944 (offset -119 lines).
> patching file src/mesh/mesh_subdiv_support.C
> patching file src/mesh/vtk_io.C
> patching file src/quadrature/quadrature_gauss_2D.C
> patching file src/utils/string_to_enum.C
> 
> 
> 
> 
> 
> On Feb 24, 2014, at 9:37 AM, Roman Vetter <vet...@et...> wrote:
> 
>>> And if you're not comfortable generating the pull request I could help - if you send along the patch I can try and break it up into number of smaller changes on a new branch, and we can start discussion.
>> 
>> I'm very new to git, and it's all still a bit confusing, so I think I'll gladly accept the help. :)
>> 
>> Here's the patch. You'll need to run ./bootstrap as I didn't include the autoconf/automake/libtool output.
>> 
>> A few more explanations on the code:
>> 
>> 1. As already mentioned (also by Norbert), the solution on a given element depends on the 1-ring of that element (i.e., the direct neighbor elements). Obviously, boundary elements lack such neighbors. Therefore, subdivision meshes require special preparation, where an additional layer of elements is added along the mesh boundaries. These additional elements do not belong to the physical domain.
>> 
>> 2. The added boundary elements are named "ghost" elements in the literature. I guess this name somewhat clashes with the "ghost" elements that lie on processor domain boundaries.
>> 
>> 3. Any program using subdivision surface elements will need to operate only on non-ghost elements. To this end, a new element type TRI3SD is added, providing the is_ghost() member.
>> 
>> 4. Nodes that have valence 6 are called "regular", otherwise they are "irregular". Elements are regular iff all their nodes are regular. Regular elements have exactly 12 shape functions (quartic box splines). Irregular elements, however, need special treatment.
>> 
>> 5. Even though the subdivision surface shape functions are quartic, one Gauss point per element is perfectly sufficient. The traditional theoretical lower bound (predicting a minimum of 6 points for triangular elements with quartic shape fcts) doesn't apply due to the overlapping subdiv shape functions.
>> 
>> 6. For efficiency, we internally reorder the nodes of TRI3SD elements in such a way that if the elements is irregular, the irregular vertex is always the first (see also http://sourceforge.net/mailarchive/message.php?msg_id=20808509) and only the first. Clearly, this means that only meshes with elements with at most one irregular vertex are supported. (The mesh preparator will properly complain otherwise.)
>> 
>> 7. The custom DofMap originally mentioned by Norbert (http://sourceforge.net/mailarchive/message.php?msg_id=20778890) was avoided in the present implementation by generalizing the way DofMap computes the dof_indices.
>> 
>> 8. Due to 1., boundary conditions are non-trivial to impose. Have a look at miscellaneous_ex11 or the original paper (Int. J. Numer. Meth. Engng. 47, 2039-2072 (2000)) for one way to impose them. See Int. J. Numer. Meth. Eng. 61, 380–405 (2004) for an alternative constraint approach.
>> 
>> 9. I don't know what happens if a user attempts to use AMR, libmesh's boundary functionality, or constraints on the subdivision surface elements. I simply haven't tried.
>> 
>> Feel free to ask more questions.
>> 
>> -Roman
>> <0001-Add-Loop-subdivision-surface-elements.patch>------------------------------------------------------------------------------
>> Flow-based real-time traffic analytics software. Cisco certified tool.
>> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
>> Customize your own dashboards, set traffic alerts and generate reports.
>> Network behavioral analysis & security monitoring. All-in-one tool.
>> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk_______________________________________________
>> Libmesh-devel mailing list
>> Lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/libmesh-devel
> 
> ------------------------------------------------------------------------------
> Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
> With Perforce, you get hassle-free workflows. Merge that actually works. 
> Faster operations. Version large binaries.  Built-in WAN optimization and the
> freedom to use Git, Perforce or both. Make the move to Perforce.
> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk_______________________________________________
> Libmesh-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmesh-devel

Re: [Libmesh-devel] Loop subdivision surface elements

[John P. <jwp...@gm...>]

On Thu, Mar 6, 2014 at 10:06 AM, Kirk, Benjamin (JSC-EG311) <
ben...@na...> wrote:

> I've got this set up on
> https://github.com/libMesh/libmesh/tree/subdivision_surfaces
>
> (subdivision_surfaces branch)
>
> the new example, misc11, runs.  I applied the patch as-is and then needed
> to make some small tweaks to avoid duplicate symbols from template
> functions, these tend to show up on OSX when they can be hidden on linux.
>
> Anyone (John?) want to help me rebase it against master?  mostly
> whitespace issues...
>

Absolutely, I have some experience with this... :-/

-- 
John

Re: [Libmesh-devel] Loop subdivision surface elements

[Kirk, B. (JSC-EG311) <ben...@na...>]

The only real collision I think might be in there is in DofMap, I believe Derek just extended the API and this does as well.

Thanks John!

-Ben


On Mar 6, 2014, at 11:21 AM, "John Peterson" <jwp...@gm...<mailto:jwp...@gm...>> wrote:




On Thu, Mar 6, 2014 at 10:06 AM, Kirk, Benjamin (JSC-EG311) <ben...@na...<mailto:ben...@na...>> wrote:
I've got this set up on https://github.com/libMesh/libmesh/tree/subdivision_surfaces

(subdivision_surfaces branch)

the new example, misc11, runs.  I applied the patch as-is and then needed to make some small tweaks to avoid duplicate symbols from template functions, these tend to show up on OSX when they can be hidden on linux.

Anyone (John?) want to help me rebase it against master?  mostly whitespace issues...

Absolutely, I have some experience with this... :-/

--
John

Re: [Libmesh-devel] Loop subdivision surface elements

[John P. <jwp...@gm...>]

On Thu, Mar 6, 2014 at 10:34 AM, Kirk, Benjamin (JSC-EG311) <
ben...@na...> wrote:

>  The only real collision I think might be in there is in DofMap, I
> believe Derek just extended the API and this does as well.
>
>  Thanks John!
>

OK, just finished the rebasing and pushed the result up to
subdivision_surfaces_rebased.

Haven't even tested if it still compiles, but will do so.  The previous
branch can stick around for comparison purposes or eventually be deleted...

-- 
John

Re: [Libmesh-devel] Loop subdivision surface elements

[John P. <jwp...@gm...>]

On Thu, Mar 6, 2014 at 12:02 PM, John Peterson <jwp...@gm...> wrote:

>
>
>
> On Thu, Mar 6, 2014 at 10:34 AM, Kirk, Benjamin (JSC-EG311) <
> ben...@na...> wrote:
>
>>  The only real collision I think might be in there is in DofMap, I
>> believe Derek just extended the API and this does as well.
>>
>>  Thanks John!
>>
>
> OK, just finished the rebasing and pushed the result up to
> subdivision_surfaces_rebased.
>
> Haven't even tested if it still compiles, but will do so.  The previous
> branch can stick around for comparison purposes or eventually be deleted...
>

So everything does indeed compile for me, but I found that I had to run
'make' in examples/miscellaneous/miscellaneous_ex11 in order to force it to
link the square_mesh.off file.  Just running 'make run' didn't seem to do
this linking step.  But that's probably my own lack of understanding of
automake.

Finally, I fixed a mismatched START/STOP_LOG bug and pushed that on the new
branch.  As has been discussed, switching the logging stuff over to use
RAII would fix this.

-- 
John

Re: [Libmesh-devel] Loop subdivision surface elements

[Kirk, B. (JSC-EG311) <ben...@na...>]

> On Mar 6, 2014, at 3:15 PM, "John Peterson" <jwp...@gm...> wrote:
> 
> Just running 'make run' didn't seem to do this linking step.

Hmm...  'make check' would do the trick, I'm not even sure what 'make run' is - is that perhaps some backwards compatible syntactic sugar of ours that's malfunctioning??

Re: [Libmesh-devel] Loop subdivision surface elements

[John P. <jwp...@gm...>]

On Thu, Mar 6, 2014 at 2:18 PM, Kirk, Benjamin (JSC-EG311) <
ben...@na...> wrote:

>
> > On Mar 6, 2014, at 3:15 PM, "John Peterson" <jwp...@gm...>
> wrote:
> >
> > Just running 'make run' didn't seem to do this linking step.
>
> Hmm...  'make check' would do the trick, I'm not even sure what 'make run'
> is - is that perhaps some backwards compatible syntactic sugar of ours
> that's malfunctioning??
>

OK, yeah, typing 'make run' was probably my issue.

-- 
John