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

Create multi-level hierarchy #58

Open
4 tasks
aprokop opened this issue Apr 30, 2018 · 1 comment
Open
4 tasks

Create multi-level hierarchy #58

aprokop opened this issue Apr 30, 2018 · 1 comment
Assignees

Comments

@aprokop
Copy link
Collaborator

aprokop commented Apr 30, 2018

A semi-easy approach that may not have the best numerical properties, but will have many of the components that will be required in the long term. It is general enough that may not need to much adaptions in the future.

Specific steps:

  1. Keep around a set of "local matrix operator" objects corresponding to each "element".
    Right now, can make those small matrices. In the future mesh-free operators, this can be non-matrices, and having just apply.
  2. Construct a matrix/operator corresponding to an agglomerate.
    This has to be done without relying on a mesh. So, in the medium future, this will replace constructing a DoFHandler for a local aggregate mesh, and instead assembling an aggregate matrix out of local matrices. In the long term, this will almost a non-steps, and the agglomerate operator will need not be a matrix, and will just need an apply. An important thing here: this operator may encompass additional degrees of freedom that are not part of an agglomerate. This is due to using `A_i = RA_{\tau_i}P$ which will make it go beyond agglomerate borders.
  3. Construct prolongator the usual way.
    The only thing of notice here is that on coarse levels, all element dofs are shared with neighbors. This is a bit tricky, but should be fine as long as we can calculate the diagonal of local and global operators. I have not seen this in any of the papers, but it seems reasonable.

The MPI functionality is somewhat orthogonal here. I think it could be properly addressed keeping around some map. It will rear its ugly head when trying to deal with indices. But let me forget it for a bit.

The main code thrust here is:

  • keep local matrix/operators around
  • combine them
  • project agglomerate matrices/operators to coarse level
  • manage index mappings

This should work with a Poisson equation. However, I think this does not have great robustness as it does not creep.

@aprokop aprokop self-assigned this Apr 30, 2018
@aprokop
Copy link
Collaborator Author

aprokop commented May 2, 2018

In addition, examine implementations of multilevel hierarchies in hypre and SA-AMGe.

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

No branches or pull requests

1 participant