Re: [Libmesh-users] Multigrid techniques with libmesh

[Vijay S. M. <vi...@gm...>]

> 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 <roy...@ic...> 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
>