> We wouldn't be averse to making library > changes to enable CPU-efficient geometric multigrid
That is good to know. I'll try my best to suggest ideas to make the implementation of geometric multigrid as easy as possible, as I go through the process of using libMesh data structures. Like I mentioned, I use matrix-free methodology and do provide an option to build the matrix when necessary. So really, I could build the matrix only for the coarsest grid that user requires and that would be a lot smaller, hopefully, as compared to the finer mesh. This smaller mesh can be solved very accurately either by direct methods or iterative methods and can be used inside the newton iteration to precondition the linear iteration. I am curious on the concept of the 'view' of a mesh. For example when I have an unstructured grid, and when I coarsen uniformly twice and refine uniformly twice, would I get the exact same mesh ?! I ask this because if you use external meshers to create the initial mesh can the libmesh mesh handlers perform this operation in a pseudo inverse fashion ? If the dof_map and mesh can provide views that are consistent with the refinement or coarsening based on an initial mesh, then I do think this should be possible without too much programming effort for an external user. Of course, you would also have to propagate the mesh_data (Or again, am I the only one using this ?) which stores material information/element or create a view of it also. Roy and Ben: If you can provide a subset view of the total mesh and dof_map, it would be tremendously helpful to create a nice geometric multigrid framework with very little changes on my existing design. Also, I think it will be useful for anyone who wants to pursue the same idea for their problem of interest. Feel free to let me know if you need any help from my side. On Wed, Nov 12, 2008 at 5:43 PM, Roy Stogner <[EMAIL PROTECTED]> wrote: > > On Wed, 12 Nov 2008, Vijay M wrote: > >> Of course, I do not have any multi-grid support in my framework yet and so >> was wondering if there was a cleaner and elegant way to perform geometric >> multigrid. My main problem is that since mesh is associated with the >> EquationSystem, when I coarsen the mesh, all my systems are reinited and >> reallocated. And so it just seems too expensive to perform couple of >> cycles >> this way. > > It definitely would be. We wouldn't be averse to making library > changes to enable CPU-efficient geometric multigrid, but the amount of > work you'd have to do might not be programmer-efficient. > >> In the meanwhile, if you have suggestions to perform geometric >> multigrid, do let me know. > > I've never done it on any but toy code, so I'm not sure what the most > efficient way to do things would be. For doing multiple multigrid > cycles per Newton step I think you'd want to store all the projection > & restriction operators and the coarse grid jacobians as sparse > matrices themselves to avoid having to do redundant FEM integrations. > But that sounds like it would roughly double your memory use. > > And then there's the question of what to do with the Mesh and DoFMap. > We'd finally use the "subactive" element capabilities to provide > different active level views of the same mesh, but DoF indexing > (especially with non-Lagrange elements!) would be tricky; we'd need > to keep track of per-level global dof indices, not just the (maximum > of) 2 that we use now. > --- > Roy > ------------------------------------------------------------------------- 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
