>> This is a great idea but would almost certainly break on >> find_neighbors(). > > Interesting - I hadn't thought of that. Well, if find_neighbors() breaks you > should still be able to have a separate piece of the mesh that is 1D and copy > values back and forth between the two pieces. You can even add more entries > to the sparsity pattern and send_list so that it "ties" the two pieces of the > mesh together. > > The reason I'm in this discussion is that we're going to be doing something > similar soon.
This would be easily fixable by putting an outer loop over the dimensions of the elements in the mesh around the current find_neighbors to force elements to look at only elements of the same dimension. So it would probably also be nice to have a method in the mesh to return a set of all the dimensions it contains... Now if you want the lower dimensional element to know which higher dimensional element it is congruent with then that would take some extra doing... This would be cool though, it could easily replace the boundary_mesh hackery we currently do for postprocessing. -Ben ------------------------------------------------------------------------------ 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
