Feast solver - internal memory error

[Alan_Ritchie]

Hi all.

Calling dfeast_scsrgv, it returns with info=-1, an internal memory error.

The output is 

Extended Eigensolvers: Size subspace 10

Extended Eigensolvers: Resize subspace 0

Extended Eigensolvers: Error with Internal memory allocation

I don't know if the error message is accurate, I am using the 64-bit version (11.1.0.103, Windows), and the matrices are pretty small, so it would need to be allocating a huge amount of memory to run out of address space. 

Is it trying to create a temporary file - my C: drive is a SSD without much space left? Changing the program working directory to E: does not help, so is it creating a file in a specific location?

Is it a problem with the matrices - the Extended Eigensolver Functionality page in the help says A should be real symmetric, and B should be real symmetric positive definite - I don't have these, I have real symmetric positive definite, and B is real symmetric, about half of the rows in B (and corresponding columns) are zero, ie it could be reordered to  - this isn't positive definite, the submatrix isn't either, so should return an error of -3?  But it seems to solve this for a different search range of eigenvalues (possibly the change makes some internally generated matrix much larger?)

Mathematically, the zeroes in the B matrix should give eigenvalues of +inf, and an eigenvector that is +1 for the entry corresponding to the matrix row, and zero for all other values, for each row/column that is zero.  The other eigenvalues can be found by generating a modified A matrix - I dont know if the FEAST solver will do this internally, and solve the modified problem, or if these eigenvalues all get rejected because the search range is bounded, and the solver just works without B actually being positive definite.

The alternative is to solve the reverse problem, swapping A and B, and solving for 1/λ, but then the range of eigenvalues gets inverted, and I need to find the largest instead of the smallest.  I might use ARPACK or something for this, FEAST doesnt seem particularly well suited for finding the largest.

Attached is a test program, and the a, b matrices.  If changed to search a different range, test program will find 4 eigenvalues around 182.9, then another 4 around 228.

The benchmark I am testing against suggests I should find a couple of eigenvalues between 1 and 5, but I don't have access to Matlab to check my matrices directly, so the difference might be the matrices I am solving.

 So, questions are:

1. Is the out of memory error message correct, or is it a different problem?
2. Does B have to be positive definite?
3. Should I always be getting an error message with any matrix of this shape?
4. Are the values found accurate, or is B not being pos def causing FEAST to find a totally wrong solution?

Thanks,

Alan

[Gennady_F_Intel]

thanks for the example - we will check the problem and will back soon

[Gennady_F_Intel]

I reproduced the  behavior on my side.   dfeast_scsrgv is not trying to create a temporary file.   In the case if the dfeast_scsrgv doesn't find the EV into proposed search intervals then the additional memory has not been alloacated and dfeast_scsrgv returns -1. In some cases this return code indicate to the runtime error, but not in that case. Actually, we need to improve the description when this situation happens. 

Also, matrix B should be SPD.  I will ask the Feast expert to look at this problem and help you to work around of this issue.

[Roman_A_Intel]

Hi Alan,

Thank you for using MKL Extended Eigensolver functionality.

1. Is the out of memory error message correct, or is it a different problem? - It is known problem appeared in case of absence eigenvalues in search interval set by user or matrix B is not positive define. So the problem here is incorrect output value of error.

2. Does B have to be positive definite? You are correct, matrix B have to be SPD.

3, 4. In case of semi-define matrix B we expect that EE functionality find eigenvalue with sufficiently good accuracy but cannot guarantee this fact. In any case if you achieve totally wrong eigenvalues in your example in case of such specific B could you send it to us to reproduce it on our side?

Thanks!