ComplexWarning in PyAMG 2.0 (but not earlier versions)

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Calling smoothed_aggregation_solve from Circuitscape 
2.
3.

What is the expected output? What do you see instead?
Older versions produced no warning.  Now we see this warning:

C:\python27\lib\site-packages\pyamg\util\linalg.py:233:
ComplexWarning: Casting complex values to real discards the imaginary
part
 H[i,j] = numpy.dot(numpy.conjugate(numpy.ravel(v)), numpy.ravel(w))

What version of the product are you using? On what operating system?
Version 2.0 on both Windows 7 64bit and Windows xp 32bit

Please provide any additional information below.

Main concern at the moment is whether this warning is benign or something to 
worry about.

Original issue reported on code.google.com by mc...@circuitscape.org on 10 Jan 2012 at 5:18

[GoogleCodeExporter]

Thanks for reporting this.  I think this is due to recent changes in Numpy.  
We'll take a look.

Original comment by luke.ol...@gmail.com on 10 Jan 2012 at 5:22

• Changed state: Accepted
• Added labels: OpSys-All

[GoogleCodeExporter]

Hi,

Thanks for reporting this.  I had some trouble reproducing this warning, so I 
was hoping that you could share a short code snippet that produces the warning 
on your machine.

Also, could you report what 
>>> import numpy
>>> numpy.version.version
produces on your machine?

and what
>>> import scipy
>>> A = scipy.sparse.csr_matrix( 1.0j*scipy.rand(3,3))
>>> print(A.dtype == complex)
produces on your machine?

Last, do you know if any of the matrices that you're using are of a complex 
data type?  If they are, then this may not be a spurious warning, but hopefully 
it is just spurious.

Thanks again,

Jacob

Original comment by jacob.b....@gmail.com on 18 Jan 2012 at 5:51

[GoogleCodeExporter]

Hi Jacob,

The call that causes the warning is:
self.create_amg_hierarchy(G)

Where G is a laplacian graph with one of the diagonal elements set to 0.

Numpy version produces 1.6.1.  The scipy code produces True.  None of
our matrices are complex.

-Brad

-- 
------------------------------------------------------------------------------
Brad McRae, Ph.D.
The Nature Conservancy
1917 1st Avenue
Seattle, WA 98101
Cell: 541-223-1170
Office: 206-436-6206
Fax: 206-343-5608
email: bmcrae@tnc.org
http://www.nceas.ucsb.edu/~mcrae/

Original comment by mc...@circuitscape.org on 24 Jan 2012 at 4:11

[GoogleCodeExporter]

My bad- I forgot to mention that create_amg_hierarchy calls this function:
def create_amg_hierarchy(self, G):
            ml = []
            ml = smoothed_aggregation_solver(G)

So, the problematic call boils down to the last line above, where G is
a laplacian graph with one of the diagonal elements set to 0.

-Brad

-- 
------------------------------------------------------------------------------
Brad McRae, Ph.D.
The Nature Conservancy
1917 1st Avenue
Seattle, WA 98101
Cell: 541-223-1170
Office: 206-436-6206
Fax: 206-343-5608
email: bmcrae@tnc.org
http://www.nceas.ucsb.edu/~mcrae/

Original comment by mc...@circuitscape.org on 24 Jan 2012 at 7:40

[GoogleCodeExporter]

Hey Brad,

Thanks for the reply.  Since your matrix is not actually complex, my
suspicion is that this warning isn't a big deal.  But, I'm still not
able to reproduce the warning on my system.  I just tried some simple
graph Laplacian examples, but couldn't get it.

If it's easy, could you email me (jacob.b.schroder - gmail) an example
G that gives you this warning when you call
smoothed_aggregation_solver(G)?  You probably already know this, but
scipy.io.savemat() is an easy way to store sparse matrices to disk.

Thanks again,

Jacob

Original comment by jacob.b....@gmail.com on 25 Jan 2012 at 6:28

[GoogleCodeExporter]

Update:  I think that I have this figured out.  In v2.0, we have this line in 
linalg.py:approximate_spectral_radius
H  = numpy.zeros((maxiter+1,maxiter), dtype=A.dtype)

But this was changed later in r815 in the trunk to
H  = numpy.zeros((maxiter+1,maxiter), dtype=v0.dtype)

Basically, the approximate_spectral_radius routine can generate an imaginary 
part for the approximate eigenvectors/values for nonsymmetric matrices (like 
DinvA).  When these approximate eigenvectors are then fed back into 
_approximate_eigenvalues as initial guesses during the adaptive cycling in 
approximate_spectral_radius, then A.dtype is no longer the right type to use 
for H.  H needs to be complex.

So, I think if circuitscape switches to the trunk this Warning will disappear.  
If not, then please let us know.

Skipping over all the techno gibberish, if circuitscape continues to use v2.0, 
I don't think that this is too big of an issue.  The spectral radius estimates 
just might be a little less accurate because the adaptive cycling will be a 
little off.

Pending any feedback from Brian, I think this ticket can eventually be closed.

- Jacob

Original comment by jacob.b....@gmail.com on 10 Feb 2012 at 11:44

[GoogleCodeExporter]

Thank you Jacob!  I'm sorry I didn't get back to you before on the
residual norm, as I haven't had time to dive in deeper.  We'll give
the trunk a try.

Best,
Brad

-- 
------------------------------------------------------------------------------
Brad McRae, Ph.D.
The Nature Conservancy
1917 1st Avenue
Seattle, WA 98101
Cell: 541-223-1170
Office: 206-436-6206
Fax: 206-343-5608
email: bmcrae@tnc.org
http://www.nceas.ucsb.edu/~mcrae/

Original comment by mc...@circuitscape.org on 11 Feb 2012 at 12:01

[GoogleCodeExporter]

Hi Brad,

I just noticed that this ticket was still open.  Has this issue been resolved 
on your end, so that it can be closed?

Thanks,

Jacob

Original comment by jacob.b....@gmail.com on 5 Aug 2012 at 6:59

[GoogleCodeExporter]

Hi Jacob,

I installed the most recent release, and have not noticed the problem.  So
yes, I believe it is resolved.  Thanks!
Brad

-- 
------------------------------------------------------------------------------
Brad McRae, Ph.D.
The Nature Conservancy
North America Region
1917 1st Avenue
Seattle, WA 98101
Cell: 541-223-1170
Fax: 206-343-5608
email: bmcrae@tnc.org
http://www.nceas.ucsb.edu/~mcrae/

Original comment by mc...@circuitscape.org on 5 Aug 2012 at 3:39

[GoogleCodeExporter]

Original comment by jacob.b....@gmail.com on 5 Aug 2012 at 4:30

• Changed state: Fixed

[GoogleCodeExporter]

moved to github:
https://github.com/pyamg/pyamg/issues

Original comment by luke.ol...@gmail.com on 8 Jul 2013 at 3:51