dolfinx icon indicating copy to clipboard operation
dolfinx copied to clipboard

Introduction of transfer operator assembly for geometric multigrid

Open schnellerhase opened this issue 1 year ago • 6 comments

Depends on (and contains) https://github.com/FEniCS/dolfinx/pull/3581 and https://github.com/FEniCS/dolfinx/pull/3661

TODO

  • [x] Check assumptions on space, for example $P^1$.
  • [ ] export of assemble_transfer_matrix should use vectorized callback
  • [ ] extend python testing to other dimensions
  • [ ] Documentation

schnellerhase avatar Aug 22 '24 12:08 schnellerhase

Failing tests best fixed after https://github.com/FEniCS/dolfinx/issues/3443.

schnellerhase avatar Oct 20 '24 20:10 schnellerhase

I've taken a look at this and it's not clear what spaces/elements are supported (and in turn, meshes with which topological dimension). Can you clarify that?

jhale avatar Nov 21 '24 08:11 jhale

Currently only $P^1$, scalar valued, but on any topological dimension. The extension to vector valued should require no big change. But other elements or higher degrees will require more work. Especially currently I take the connectivity information for the operators from the mesh, instead of working with the dof maps. So I guess as long as Dofmap is the identity this approach should apply for now.

schnellerhase avatar Nov 21 '24 09:11 schnellerhase

I think support for block size should be relatively straightforward to add.

The P1 limitation is more pressing - am I right in saying at the moment the code says mesh vertices == p1 dofs? So to generalise it you would need to look at the entities/dofs across all topological dimensions?

jhale avatar Nov 21 '24 13:11 jhale

The P1 limitation is more pressing - am I right in saying at the moment the code says mesh vertices == p1 dofs?

Indeed. This currently computes the transfer operation by taking the neighborhood info from the mesh topology and not from the DOF maps.

schnellerhase avatar Nov 21 '24 13:11 schnellerhase

Also the implementation of the current inclusion map computation here, is very much brute force - checking all points and requiring an all to all communication step. However I couldn't think about a better general solution. However the data structure I believe is very well suited for the transfer operation as it makes clear how one mesh is to be recovered in another. So, better it would be if one can produce such an inclusion mapping as a by product, as for example of the refinement operation.

schnellerhase avatar Nov 21 '24 13:11 schnellerhase