numarray problem with Leginon 1.3 on SUSE 10.3
Added by Anonymous over 17 years ago
I installed Leginon 1.3 on a new SUSE 10.3 system. When I run start-leginon.py it gets through the wizard at the start; but when I pick an application to launch I get the following output:
Exception in thread data binder handler thread:
Traceback (most recent call last):
File "/usr/lib64/python2.5/threading.py", line 460, in __bootstrap
self.run()
File "/usr/lib64/python2.5/threading.py", line 440, in run
self.__target(*self.__args, **self.__kwargs)
File "/usr/local/lib64/python2.5/site-packages/Leginon/databinder.py", line 13
1, in handleData
method(args)
File "/usr/local/lib64/python2.5/site-packages/Leginon/launcher.py", line 76,
in onCreateNode
n = nodeclass(nodename, session, managerlocation, **kwargs)
File "/usr/local/lib64/python2.5/site-packages/Leginon/manualacquisition.py",
line 63, in init
self.dosecal = calibrationclient.DoseCalibrationClient(self)
File "/usr/local/lib64/python2.5/site-packages/Leginon/calibrationclient.py",
line 301, in init
CalibrationClient.__init__(self, node)
File "/usr/local/lib64/python2.5/site-packages/Leginon/calibrationclient.py",
line 59, in init
self.peakfinder = peakfinder.PeakFinder()
File "/usr/local/lib64/python2.5/site-packages/Leginon/peakfinder.py", line 29
, in init
gauss = convolver.gaussian_kernel(lpf)
File "/usr/local/lib64/python2.5/site-packages/Leginon/convolver.py", line 149
, in gaussian_kernel
k = Numeric.fromfunction(i, (n,n))
File "/usr/local/lib64/python2.5/site-packages/numarray/generic.py", line 1176
, in fromfunction
return apply(function, tuple(indices(dimensions, type)))
File "/usr/local/lib64/python2.5/site-packages/numarray/generic.py", line 1164
, in indices
a = concatenate(ufunc.nonzero(_nc.ones(shape)))
File "/usr/local/lib64/python2.5/site-packages/numarray/generic.py", line 1110
, in concatenate
return _concat(arrs)
File "/usr/local/lib64/python2.5/site-packages/numarray/generic.py", line 1100
, in _concat
dest[ix:ix+_shape0(a)]._copyFrom(a)
File "/usr/local/lib64/python2.5/site-packages/numarray/generic.py", line 613,
in _broadcast
return _broadcast(arr, self._shape)
File "/usr/local/lib64/python2.5/site-packages/numarray/generic.py", line 94,
in _broadcast
raise ValueError("Arrays have incompatible shapes")
ValueError: Arrays have incompatible shapes
/home/bmswvn>
bmswvn@fbsapcd002:~>
I've tried installing a variety of different versions of numarray, assuming the latest version may be incompatible in some way; but this doesn't help. (The versions of numarray tried include the latest version and also 1.1.1 - it was hard to find source for numarray 1.1.1 to allow installation on the SUSE 10.3 system; but numarray 1.1.1 is the version on my working Leginon system. However, downgrading to numarray 1.1.1 does not help on the SUSE 10.3 anyway.) Any suggestions?
William
Replies (4)
- Added by Jim Pulokas over 17 years ago
Here is one thing to try:
Maybe Numeric is being used instead of numarray. Some of this old Leginon code tries to import numarray, but if it fails, it will import Numeric instead. Open a python command line and try to import numarray. If it fails, try to import Numeric. If numarray fails, and Numeric works, then this is probably what is happening in the convolver.py module.
If that is not the problem, try to figure out what value is being passed to the gaussian_kernel function to cause this error. Or maybe it does not matter what value is passed to the function. Try calling that function from a command line like this:
import convolver convolver.gaussian_kernel(x)but replace x with different values to see if you can cause the exception. Maybe it is a negative value, or 0, or a very high value. Or if every value causes the exception, then there is a more serious problem.
Sometimes problems with numarray are cause by a left over library that is installed from a previous version, so try to make sure that everything is cleaned out from previous numarray or Numeric versions.
- Added by Anonymous over 17 years ago
"pulokas" wrote: Here is one thing to try:
Maybe Numeric is being used instead of numarray. Some of this old Leginon code tries to import numarray, but if it fails, it will import Numeric instead. Open a python command line and try to import numarray. If it fails, try to import Numeric. If numarray fails, and Numeric works, then this is probably what is happening in the convolver.py module.
If that is not the problem, try to figure out what value is being passed to the gaussian_kernel function to cause this error. Or maybe it does not matter what value is passed to the function. Try calling that function from a command line like this:
import convolver convolver.gaussian_kernel(x)but replace x with different values to see if you can cause the exception. Maybe it is a negative value, or 0, or a very high value. Or if every value causes the exception, then there is a more serious problem.
Sometimes problems with numarray are cause by a left over library that is installed from a previous version, so try to make sure that everything is cleaned out from previous numarray or Numeric versions.
I've confirmed that numarray is being used, not Numeric. With a modification to convolver.py to give some extra output, I found that the value 1.5 is passed to the function. (As this is a low positive value it doesn't fit into any of the problematic types of value listed above.)
William
- Added by Anonymous over 17 years ago
"pulokas" wrote: Here is one thing to try:
Maybe Numeric is being used instead of numarray. Some of this old Leginon code tries to import numarray, but if it fails, it will import Numeric instead. Open a python command line and try to import numarray. If it fails, try to import Numeric. If numarray fails, and Numeric works, then this is probably what is happening in the convolver.py module.
As I said before, numarray is successfully imported by convolver.py not Numeric, and this standard version of the Leginon 1.3 convolver causes the exception. However, if I modify convolver.py to always import Numeric then it seems to start the application okay i.e. Numeric does not cause the problem, it seems to fix the problem if convolver.py always imports Numeric. (This still leaves the worry that there is some incompatibility with numarray on my platform - SUSE 10.3, 64-bit, etc - that will cause problems in other code in Leginon; as I notice a very large number of Leginon source code files import numarray),
William
- Added by Anonymous over 17 years ago
"WVNicholson" wrote: > "pulokas" wrote: Here is one thing to try:
Maybe Numeric is being used instead of numarray. Some of this old Leginon code tries to import numarray, but if it fails, it will import Numeric instead. Open a python command line and try to import numarray. If it fails, try to import Numeric. If numarray fails, and Numeric works, then this is probably what is happening in the convolver.py module.
As I said before, numarray is successfully imported by convolver.py not Numeric, and this standard version of the Leginon 1.3 convolver causes the exception. However, if I modify convolver.py to always import Numeric then it seems to start the application okay i.e. Numeric does not cause the problem, it seems to fix the problem if convolver.py always imports Numeric. (This still leaves the worry that there is some incompatibility with numarray on my platform - SUSE 10.3, 64-bit, etc - that will cause problems in other code in Leginon; as I notice a very large number of Leginon source code files import numarray),
William
However, other code (in mosaic.py) fails because of numarray-related problems and it can't be fixed so easily,
William