-
-
Notifications
You must be signed in to change notification settings - Fork 182
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
base: main
Are you sure you want to change the base?
Conversation
fcf9207
to
b21cc50
Compare
8c70703
to
33a3fd4
Compare
33a3fd4
to
48ee84a
Compare
Failing tests best fixed after #3443. |
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? |
Currently only |
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? |
Indeed. This currently computes the transfer operation by taking the neighborhood info from the mesh topology and not from the DOF maps. |
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. |
TODO
Requires prior merge of #3362