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
