You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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.
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.
The text was updated successfully, but these errors were encountered:
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:
Right now, can make those small matrices. In the future mesh-free operators, this can be non-matrices, and having just
apply
.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 anapply
. 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.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:
This should work with a Poisson equation. However, I think this does not have great robustness as it does not creep.
The text was updated successfully, but these errors were encountered: