Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project!

## libmesh-devel

 [Libmesh-devel] Loop subdivision surface elements From: Roman Vetter - 2014-02-21 13:53:25 ```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 From: Paul T. Bauman - 2014-02-21 16:20:55 Attachments: Message as HTML ```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 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 > Libmesh-devel@... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel > ```
 Re: [Libmesh-devel] Loop subdivision surface elements From: Kirk, Benjamin (JSC-EG311) - 2014-02-21 17:11:33 ```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 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 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 > Libmesh-devel@... > 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 > Libmesh-devel@... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel ```
 Re: [Libmesh-devel] Loop subdivision surface elements From: David Knezevic - 2014-02-21 17:55:25 Attachments: Message as HTML ```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 > 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 > Libmesh-devel@... > > 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 > Libmesh-devel@... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel ```
 Re: [Libmesh-devel] Loop subdivision surface elements From: Derek Gaston - 2014-02-21 18:31:29 Attachments: Message as HTML ```Another vote for shells - this would be super handy... Derek On Fri, Feb 21, 2014 at 9:55 AM, David Knezevic 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 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 >> Libmesh-devel@... >> 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 listLibmesh-devel@...nethttps://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 > Libmesh-devel@... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel > > ```
 Re: [Libmesh-devel] Loop subdivision surface elements From: Roman Vetter - 2014-02-24 15:37:32 Attachments: 0001-Add-Loop-subdivision-surface-elements.patch ```> 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 From: Roy Stogner - 2014-02-24 16:03:57 ```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 From: Roman Vetter - 2014-03-04 07:41:54 ```Has anyone had time to give it a look? -Roman ```
 Re: [Libmesh-devel] Loop subdivision surface elements From: Kirk, Benjamin (JSC-EG311) - 2014-03-06 13:56:24 Attachments: smime.p7s ```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 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 > Libmesh-devel@... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel ```
 Re: [Libmesh-devel] Loop subdivision surface elements From: Roman Vetter - 2014-03-06 15:20:35 ```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 From: Kirk, Benjamin (JSC-EG311) - 2014-03-06 17:06:55 Attachments: smime.p7s ```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) 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 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 >> Libmesh-devel@... >> 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 > Libmesh-devel@... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel ```
 Re: [Libmesh-devel] Loop subdivision surface elements From: John Peterson - 2014-03-06 17:21:06 Attachments: Message as HTML ```On Thu, Mar 6, 2014 at 10:06 AM, Kirk, Benjamin (JSC-EG311) < benjamin.kirk@...> 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 From: Kirk, Benjamin (JSC-EG311) - 2014-03-06 17:34:44 Attachments: Message as HTML ```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" > wrote: On Thu, Mar 6, 2014 at 10:06 AM, Kirk, Benjamin (JSC-EG311) > 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 From: John Peterson - 2014-03-06 19:02:43 Attachments: Message as HTML ```On Thu, Mar 6, 2014 at 10:34 AM, Kirk, Benjamin (JSC-EG311) < benjamin.kirk@...> 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 From: John Peterson - 2014-03-06 21:15:15 Attachments: Message as HTML ```On Thu, Mar 6, 2014 at 12:02 PM, John Peterson wrote: > > > > On Thu, Mar 6, 2014 at 10:34 AM, Kirk, Benjamin (JSC-EG311) < > benjamin.kirk@...> 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 From: Kirk, Benjamin (JSC-EG311) - 2014-03-06 21:18:30 ```> On Mar 6, 2014, at 3:15 PM, "John Peterson" 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 From: John Peterson - 2014-03-06 21:32:03 Attachments: Message as HTML ```On Thu, Mar 6, 2014 at 2:18 PM, Kirk, Benjamin (JSC-EG311) < benjamin.kirk@...> wrote: > > > On Mar 6, 2014, at 3:15 PM, "John Peterson" > 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 ```