I would use MatGetSubMatrix() to pull out the part of the matrix you care
about and hand that matrix off to SLEPc.
Others prefer to remove the Dirichlet boundary value locations while doing
the finite element assembly, this way those locations never appear in the
The end result is the same, you have the slightly smaller matrix of interest
to compute the eigenvalues from.
> On Oct 13, 2016, at 5:48 PM, Christopher Pierce <cmpie...@wpi.edu> wrote:
> Hello All,
> As there isn't a SLEPc specific list, it was recommended that I bring my
> question here. I am using SLEPc to solve a generalized eigenvalue
> problem generated as part of the Finite Element Method, but am having
> difficulty getting the diagonalizer to converge. I am worried that the
> method used to set boundary conditions in the matrix is creating the
> problem and am looking for other people's input.
> In order to set the boundary conditions, I find the list of IDs that
> should be zero in the resulting eigenvectors and then use
> MatZeroRowsColumns to zero the rows and columns and in the matrix A
> insert a large value such as 1E10 on each diagonal element that was
> zeroed and likewise for the B matrix except with the value 1.0. That
> way the eigenvalues resulting from those solutions are on the order of
> 1E10 and are outside of the region of interest for my problem.
> When I tried to diagonal the matrices I could only get converged
> solutions from the rqcg method which I have found to not scale well with
> my problem. When using any other method, the approximate error of the
> eigenpairs hovers around 1E00 and 1E01 until it reaches the max number
> of iterations. Could having so many identical eigenvalues (~1,000) in
> the spectrum be causing this to happen even if they are far outside of
> the range of interest?
> Chris Pierce
> WPI Center for Computation Nano-Science