On Feb 8, 2012, at 6:14 PM, Roy Stogner wrote: > Only with some difficulty; it'd be the first time we put variables on > elements that didn't technically exist. > > It'd be easier (though still quite difficult) to do something we've > been wanting to for a while: extend libMesh to handle Mesh objects > with Elems of more than one dimension inside. Then you just create > the boundary mesh, add those elements into the Mesh with their own > subdomain, set a per-subdomain variable on for them, and off you go.
Are you sure this does't work right now? We are using lower dimension meshes in higher dimension spaces right now… and I can't see why having some elements that are 2D and some that are 1D in the same mesh wouldn't work. You might even be able to tie them together by using the same nodes (so that the solutions are continuous and the sparsity pattern is correct). You might not be able to read this mesh from a file (although I think Exodus supports it). But if you just manually add a 2D element to a mesh and then add a 1D element… why wouldn't it work? If you give them different subdomains then you should even be able to restrict variables to the different pieces. Derek ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
