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
In #110, we had to relax the randomization of one mesh for the algorithm to converge. This is because in that case the restrictor is not full ranked. This lead us to the discovery that we don't know how to compute the eigenvectors of the operators on an agglomerate when we have boundary conditions. When using LAPACK, we compute all the eigenvalues including the ones corresponding to the boundary conditions however these are spurious boundary conditions. ARPACK does not have this problem because we "eliminate" these eigenvalues by setting to zero the dofs corresponding to the Dirichlet BC in the initial guess. However, running ARPACK twice in a row gives different results which may indicate a stability problem. Since we plan to change the eigensolver, we need to re-investigate this problem once the eigensolver has been integrated in the code.
The text was updated successfully, but these errors were encountered:
Just thinking about ARPACK, if it uses just matrix apply for the operator, the Dirichlet dofs should be completely invisible to it. dealII transforms Dirichlet dof rows (and columns) to 0, and puts some value on the diagonal. By modifying the corresponding value in the initial guess to zero, we essentially apply diagonal to 0, resulting in zero. Thus, any eigenvectors that ARPACK computes should theoretically be only for the non-Dirichlet portion of the operator. However, it does not seem to be the case.
Another thing to note is that ARPACK solves the generalized eigenproblem. We set B = I there, so that should not be the source of the problem.
In #110, we had to relax the randomization of one mesh for the algorithm to converge. This is because in that case the restrictor is not full ranked. This lead us to the discovery that we don't know how to compute the eigenvectors of the operators on an agglomerate when we have boundary conditions. When using
LAPACK
, we compute all the eigenvalues including the ones corresponding to the boundary conditions however these are spurious boundary conditions.ARPACK
does not have this problem because we "eliminate" these eigenvalues by setting to zero the dofs corresponding to the Dirichlet BC in the initial guess. However, runningARPACK
twice in a row gives different results which may indicate a stability problem. Since we plan to change the eigensolver, we need to re-investigate this problem once the eigensolver has been integrated in the code.The text was updated successfully, but these errors were encountered: