See this description from Jed
In a simpler way you could just scale your diagonal entries which are
1 at the moment with a value that is out of your interest range, such
that the values do not appear in the solution.
On Fri, Oct 14, 2016 at 2:01 AM, Barry Smith <bsm...@mcs.anl.gov> wrote:
> 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