Hi, We had tried installing PyFR on the RaspberryPI (just for fun :), and that was the peculiar architecture I was talking about) and faced this issue.
The common thing in all these cases is the ARM architecture and 32Bit. My understanding is that this a bug in numpy ARM version where as stated above np.intp==np.int32 gives a false, where np.intp is np.int32 , whereas in other machines it gives a positive, which seems to be the bug. Ok about how we got it running? It a ghastly hack. Replace all occurances of np.intp to np.int32. A quick grep gives: ./backends/base/generator.py:100: argt.append([np.intp]*(2 + va.ncdim)) ./backends/base/generator.py:103: argt.append([np.intp]) ./backends/base/generator.py:106: argt.append([np.intp, np.int32]) ./backends/openmp/blasext.py:21: [np.int32] + [np.intp, y.dtype]*(1 + nv)) ./backends/openmp/blasext.py:52: 'errest', src, [np.int32] + [np.intp]*3 + [dtype]*2, restype=dtype ./backends/openmp/cblas.py:88: np.intp, np.int32, np.int32, np.int32, ./backends/openmp/cblas.py:89: a.dtype, np.intp, np.int32, np.intp, np.int32, ./backends/openmp/cblas.py:90: a.dtype, np.intp, np.int32 Just replace those intps, and hopefully things should work. But then that version wont work on the 64bit machines I do not remember now of any other problem that we faced on RPI. Let us know. Regards Arvind On Thu, Jun 18, 2015 at 4:47 PM, Miquel Vidal <[email protected]> wrote: > Hi, > > I've been checking this post in hope for a solution, because I'm > experiencing the same problem. > > Versions 0.2.4, 0.3.0 and 0.8.0 all have this problem. > > I've been trying to execute the program in an ARM architecture without > success. The output of 'uname -a' is the following: > Linux mb-1101 3.11.0-bsc_opencl+ #1 SMP Wed Dec 10 16:31:28 CET 2014 > armv7l armv7l armv7l GNU/Linux > > And the output of the Python commands: > >>> import numpy as np > >>> np > <module 'numpy' from > '/usr/local/lib/python3.4/dist-packages/numpy/__init__.py'> > >>> np.intp > <class 'numpy.int32'> > >>> np.intp==np.int32 > False > > Could it be an architecture problem, as Arvind comments in the previous > message? > > I've tried uninstalling and reinstalling all numpy instances, as well as > python3.4 itself. None of that solutions worked. Is there anything else > that I could try? > > Thank you very much. > > Miquel Vidal > > El dijous, 18 juny de 2015 0:24:46 UTC+2, arvind iyer va escriure: >> >> Hi, >> >> Please do as Freddie suggested, that is indeed the recommended way. But >> could you please mail the output of >> uname -a >> >> and the output of the following when typed in ipython? >> >> import numpy as np >> np >> np.intp >> np.intp==np.int32 >> >> I ask because I have seen this problem on one particular architecture. >> >> Regards >> Arvind >> >> On Wed, Jun 17, 2015, 23:03 Karl Napf <[email protected]> wrote: >> >>> Dear Peter, >>> >>> thank you for your reply! >>> I recently switched to anaconda as my package manager. I installed the >>> following packages: >>> >>> h5py 2.5.0 np19py34_2 >>> mako 1.0.1 <pip> >>> mpi4py 1.3.1 <pip> >>> numpy 1.9.2 py34_0 >>> python 3.4.3 1 >>> pytools 2014.3.5 <pip> >>> mpmath 0.19 <pip> >>> >>> Then I went on installing PyFr 0.8.0 by issuing *python setup.py >>> install*. There was no error and PyFr also appeared in *conda list* >>> afterwards. >>> I also installed OpenBLAS-0.2.14 and I have gcc 4.8.2. >>> >>> Since I'm currently working on a laptop without any notable graphics >>> acceleration I wanted to use the OpenMP backend for multicore CPUs. >>> >>> I generally followed the couette flow instructions. I edited the >>> *couette_flow_2d.ini* and modified the openmp-backend section: >>> [backend-openmp] >>> cblas = /opt/OpenBLAS/lib/libopenblas.so >>> cc = gcc >>> cblas-type = parallel >>> >>> I was able to convert the Gmsh file without any error. I then tried to >>> run pyfr using >>> *pyfr run --backend openmp couette_flow_2d.pyfrm couette_flow_2d.ini* >>> >>> This then resulted in the known numpy.int32 error: >>> * _pickle.PicklingError: Can't pickle <class 'numpy.int32'>: it's not >>> the same object as numpy.int32* >>> >>> I hope this helps. Any idea what I did wrong? I would really love to >>> play around with PyFR a bit! >>> >>> Best regards >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "PyFR Mailing List" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at http://groups.google.com/group/pyfrmailinglist. >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- > You received this message because you are subscribed to the Google Groups > "PyFR Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/pyfrmailinglist. > For more options, visit https://groups.google.com/d/optout. > -- ================================ Dr. Iyer Arvind Sundaram The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man - George Bernard Shaw. -- You received this message because you are subscribed to the Google Groups "PyFR Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send an email to [email protected]. Visit this group at http://groups.google.com/group/pyfrmailinglist. For more options, visit https://groups.google.com/d/optout.
