>> Recently, subdivision surfaces were suggested as an alternative way to >> construct C1 (and higher) conforming surface meshes for finite element >> simulations. > > Interesting. I've heard of subdivision elements being used for > surface mesh refinement, but in a context where the subdivision > surface was only C1 in the limiting sense; each discrete mesh was > still faceted. We could do something like that relatively easily, but > of course it wouldn't be as accurate unless your formulation is > insensitive to domain boundary discontinuities.
If we had a C1 mapping element I'd think we could project the C0 subdivision surface into the C1 space... In fact, I think we would almost always have to do this with any mapping element other than Lagrange. (Does anyone know of a surface mesh format which specifies the coordinates in terms of e.g. Clough-Tocher basis weights?) It seems like using anything other than Lagrange would involve a 'startup' phase where we declare a system on top of lagrange-mapped FEs in the usual way, solve an L2 projection or something to get the geometry on the desired mapping basis, and then redefine the mesh somehow, probably with an out-of-core write/restart file... But that's just a detail. >> Assuming triangular elements, the subdivision surface approach results >> in 12 b-spline shape functions per element. The isoparametric map to >> real space is a combination of them multiplied with the real space >> position of the triangle's nodes *and* its next neighbor nodes (the >> 1-ring of triangles around the element). > > This is a problem, but a minor one - the nodal neighbor elements > always exist as at least ghost elements on even a distributed mesh, > and I think we've already got some nice Patch API for accessing them; > it probably wouldn't be hard to write something similar for collecting > the set of only all nodal neighbors on a surface. > >> Looking at existing libmesh elements (lagrange, clough), I see that only >> the ::shape, ::shape_deriv and ::shape_second_deriv are typically >> overwritten, and the mapping to real space is done by libmesh >> (fe_base.C, I think). That is correct... > This would be much harder, because to do the mapping right would > require a major code refactoring. Right now, we combine a geometric > element Elem and a finite element space FE to produce results, and > it's understood that the mapping is always done by a Lagrange FE. > We'd probably want to add a mapping element (returned from a factory > method in Mesh?) to that combination, and I suspect that because of > the way they calculate shape functions, most of our FE objects would > not be immediately suitable as mapping objects. To keep the code anything resembling efficient, we'd need to make sure multiple mapping types are supported at the same time... I'd think we want to use the C1 map *only* on elements with a face or edge trace on the boundary of interest. >> As pointed out above, the subdivision elements have a special mapping to >> real space, which needs to take the neighboring nodes' position into >> account. Is there a way to accomplish this in the current code > > No. > >> or would it be possible to extend it in that way? > > Yes, but not easily. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
