(I'm copying this to the -devel list, feel free to take -users off any reply to keep its traffic down)
> Okay, so dxyz seems to be appropriate for storing the metric - that > problem is solved then. Now, one last thing: All DOFs are at the > vertices (and we have only one DOF per vertex). Ie the global vector and > matrices have dimension M or MxM if M is the number of mesh vertices. > However, each DOF is not only shared with all the triangles incident to > that vertex, but also with all elements which have this vertex in their > patch (ie in their 1-neighborhood). E.g., for the element e shown below, > the element matrix contribution Ke(i,j) is a (N+6)x(N+6) matrix, where > only the local indices 0,1 and N directly belong to element e, while the > other DOFs belong to the elements around e. I don't think that dof_map > can provide such a map out of the box, or am I wrong? Correct - it won't do that by default... > I was therefore thinking of the following: Create a custom > subdiv_dof_map, which collects the dof indices of all vertices in the > patch of e and then (in the correct order) combines them into one > dof_indices vector. This one can then be used as before. I guess it > would be minimally invasive and only need small changes in the > application code. I just hope there's no hidden catch... You're right. There may be bizarre AMR constraint implications I haven't thought through, but since you said you're presently not worried about AMR that is a non-issue. All that should be needed is a different method to compute the graph of the sparse matrix. (I think even the current dof distribution stuff will work just fine.) For some time I've wanted 'specialized' dof maps to handle cases where you ether (i) have special needs (like this) or (ii) know something special about your application that allows you to exploit an efficiency. My compressible navier-stokes application is an example of (ii) since there are a lot of variables in a system which are all the same type. The System base class holds an AutoPtr<DofMap> object, so I'm thinking it would be *really* easy to modify the DofMap class definition a little so that users can derive their own implementation and supply it to the System for use. Then we just add a System::replace_dof_map() member or something like that. Anyone have a different idea? -Ben >>> N+4 - N+1 - N+2 >>> / \ / \ / \ >>> / \ / \ / \ >>> N+5 -- N --- 1 -- N+3 >>> \ / \ e / \ / >>> \ / \ / \ / >>> N-1--- 0 --- 2 >>> \ /|\ / >>> \ / | \ / >>> 5 -4- 3 >>> ------------------------------------------------------------------------- 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
