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

Eigenvalues on Dirichlet BC #126

Open
Rombur opened this issue Jan 30, 2019 · 1 comment
Open

Eigenvalues on Dirichlet BC #126

Rombur opened this issue Jan 30, 2019 · 1 comment

Comments

@Rombur
Copy link
Collaborator

Rombur commented Jan 30, 2019

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.

@aprokop
Copy link
Collaborator

aprokop commented Jan 30, 2019

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.

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

2 participants