I've implemented my application using MatGetSubMatrix and the solvers
appear to be converging correctly now, just slowly.  I assume that this
is due to the clustering of eigenvalues inherent to the problem that I'm
using, however.  I think that this should be enough to get me on track
to solving problems with it.



On 10/14/16 01:43, Christopher Pierce wrote:
> Thank You,
> That looks like what I need to do if the highly degenerate eigenpairs
> are my problem.  I'll try that out this week and see if that helps.
> Chris
> On 10/13/16 20:01, Barry Smith 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 
>> matrix. 
>>    The end result is the same, you have the slightly smaller matrix of 
>> interest to compute the eigenvalues from.
>> Barry
>>> 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?
>>> Thank,
>>> Chris Pierce
>>> WPI Center for Computation Nano-Science

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to