Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduction of transfer operator assembly for geometric multigrid #3363

Draft
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

schnellerhase
Copy link
Contributor

@schnellerhase schnellerhase commented Aug 22, 2024

TODO

  • Check assumptions on space, for example $P^1$.
  • finalize python interface, probably needs some more wrapping for the matrix assembly.
  • extend python testing to other dimensions

Requires prior merge of #3362

@schnellerhase schnellerhase mentioned this pull request Aug 22, 2024
2 tasks
@jorgensd jorgensd changed the title Introduction of transfer opeartor assembly for geometry multigrid opeartions Introduction of transfer operator assembly for geometry multigrid operations Sep 19, 2024
@schnellerhase
Copy link
Contributor Author

Failing tests best fixed after #3443.

@jhale
Copy link
Member

jhale commented Nov 21, 2024

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?

@schnellerhase
Copy link
Contributor Author

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.

@jhale
Copy link
Member

jhale commented Nov 21, 2024

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?

@schnellerhase
Copy link
Contributor Author

schnellerhase commented Nov 21, 2024

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
Copy link
Contributor Author

schnellerhase commented Nov 21, 2024

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 schnellerhase changed the title Introduction of transfer operator assembly for geometry multigrid operations Introduction of transfer operator assembly for geometric multigrid operations Nov 21, 2024
@schnellerhase schnellerhase changed the title Introduction of transfer operator assembly for geometric multigrid operations Introduction of transfer operator assembly for geometric multigrid Nov 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants