Hi,
Regarding the issue Miquel had, chaning the intp instances by int32 solves
the problem with pickle on ARM 32 bits and, therefore, the application runs
correctly with OpenMP backend.
However, when running MPI+OpenMP it crashes again due to some key error
with int32. Below the specific error:
└┌(%:~/SCC/PyFR-1.0.0/couette_flow_2d)┌- mpirun -n 2 ~/.local/bin/pyfr run
-b openmp -p couette_flow_2d.pyfrm couette_flow_2d.ini
Traceback (most recent call last):
File
"/home/druiz/.local/lib/python3.4/site-packages/pyfr-1.0.0-py3.4.egg/pyfr/util.py",
line 32, in __call__
KeyError: (<function OpenMPKernelProvider._build_kernel at 0xb55a1858>,
b'(X\t\x00\x00\x00pack_viewq\x00XU\n\x00\x00\n\n#include <omp.h>\n#include
<stdlib.h>\n#include <tgmath.h>\n\n#define PYFR_ALIGN_BYTES 32\n#define
PYFR_NOINLINE __attribute__ ((noinline))\n\n#define min(a, b) ((a) < (b) ?
(a) : (b))\n#define max(a, b) ((a) > (b) ? (a) : (b))\n\n//
Typedefs\ntypedef double fpdtype_t;\n\n// OpenMP static loop scheduling
functions\n\nstatic inline int\ngcd(int a, int b)\n{\n return (a == 0) ?
b : gcd(b % a, a);\n}\n\nstatic inline void\nloop_sched_1d(int n, int
align, int *b, int *e)\n{\n int tid = omp_get_thread_num();\n int nth
= omp_get_num_threads();\n\n // Round up n to be a multiple of nth\n
int rn = n + nth - 1 - (n - 1) % nth;\n\n // Nominal tile size\n int
sz = rn / nth;\n\n // Handle alignment\n sz += align - 1 - (sz - 1) %
align;\n\n // Assign the starting and ending index\n *b = sz *
tid;\n *e = min(*b + sz, n);\n\n // Clamp\n if (*b >= n)\n
*b = *e = 0;\n}\n\nstatic inline void\nloop_sched_2d(int nrow, int ncol,
int colalign,\n int *rowb, int *rowe, int *colb, int
*cole)\n{\n int tid = omp_get_thread_num();\n int nth =
omp_get_num_threads();\n\n // Distribute threads\n int nrowth =
gcd(nrow, nth);\n int ncolth = nth / nrowth;\n\n // Row and column
indices for our thread\n int rowix = tid / ncolth;\n int colix = tid
% ncolth;\n\n // Round up ncol to be a multiple of ncolth\n int rncol
= ncol + ncolth - 1 - (ncol - 1) % ncolth;\n\n // Nominal tile size\n
int ntilerow = nrow / nrowth;\n int ntilecol = rncol / ncolth;\n\n //
Handle column alignment\n ntilecol += colalign - 1 - (ntilecol - 1) %
colalign;\n\n // Assign the starting and ending row to each thread\n
*rowb = ntilerow * rowix;\n *rowe = *rowb + ntilerow;\n\n // Assign
the starting and ending column to each thread\n *colb = ntilecol *
colix;\n *cole = min(*colb + ntilecol, ncol);\n\n // Clamp\n if
(*colb >= ncol)\n *colb = *cole = 0;\n}\n\n\n\n\nvoid\npack_view(int
n, int nrv, int ncv,\n const fpdtype_t *__restrict__ v,\n
const int *__restrict__ vix,\n const int *__restrict__
vcstri,\n const int *__restrict__ vrstri,\n fpdtype_t
*__restrict__ pmat)\n{\n if (ncv == 1)\n for (int i = 0; i < n;
i++)\n pmat[i] = v[vix[i]];\n else if (nrv == 1)\n for
(int i = 0; i < n; i++)\n for (int c = 0; c < ncv;
c++)\n pmat[c*n + i] = v[vix[i] + vcstri[i]*c];\n
else\n for (int i = 0; i < n; i++)\n for (int r = 0; r <
nrv; r++)\n for (int c = 0; c < ncv;
c++)\n pmat[(r*ncv + c)*n + i] = v[vix[i] +
vrstri[i]*r\n +
vcstri[i]*c];\n}\n\nq\x01X\x08\x00\x00\x00iiiPPPPPq\x02tq\x03.', b'}q\x00.')
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/druiz/.local/bin/pyfr", line 9, in <module>
load_entry_point('pyfr==1.0.0', 'console_scripts', 'pyfr')()
File "/usr/lib/python3/dist-packages/mpmath/ctx_mp.py", line 1301, in g
return f(*args, **kwargs)
File
"/home/druiz/.local/lib/python3.4/site-packages/pyfr-0.8.0-py3.4.egg/pyfr/scripts/main.py",
line 126, in main
File
"/home/druiz/.local/lib/python3.4/site-packages/pyfr-0.8.0-py3.4.egg/pyfr/scripts/main.py",
line 247, in process_run
File
"/home/druiz/.local/lib/python3.4/site-packages/pyfr-0.8.0-py3.4.egg/pyfr/scripts/main.py",
line 231, in _process_common
File
"/home/druiz/.local/lib/python3.4/site-packages/pyfr-0.8.0-py3.4.egg/pyfr/solvers/__init__.py",
line 14, in get_solver
File
"/home/druiz/.local/lib/python3.4/site-packages/pyfr-0.8.0-py3.4.egg/pyfr/integrators/__init__.py",
line 29, in get_integrator
File
"/home/druiz/.local/lib/python3.4/site-packages/pyfr-0.8.0-py3.4.egg/pyfr/integrators/controllers.py",
line 14, in __init__
File
"/home/druiz/.local/lib/python3.4/site-packages/pyfr-0.8.0-py3.4.egg/pyfr/integrators/steppers.py",
line 9, in __init__
File
"/home/druiz/.local/lib/python3.4/site-packages/pyfr-0.8.0-py3.4.egg/pyfr/integrators/writers.py",
line 15, in __init__
File
"/home/druiz/.local/lib/python3.4/site-packages/pyfr-0.8.0-py3.4.egg/pyfr/integrators/base.py",
line 47, in __init__
File
"/home/druiz/.local/lib/python3.4/site-packages/pyfr-0.8.0-py3.4.egg/pyfr/solvers/base/system.py",
line 59, in __init__
File
"/home/druiz/.local/lib/python3.4/site-packages/pyfr-0.8.0-py3.4.egg/pyfr/solvers/base/system.py",
line 158, in _gen_kernels
File
"/home/druiz/.local/lib/python3.4/site-packages/pyfr-0.8.0-py3.4.egg/pyfr/solvers/baseadvec/inters.py",
line 55, in <lambda>
File
"/home/druiz/.local/lib/python3.4/site-packages/pyfr-0.8.0-py3.4.egg/pyfr/backends/base/backend.py",
line 173, in kernel
File
"/home/druiz/.local/lib/python3.4/site-packages/pyfr-0.8.0-py3.4.egg/pyfr/backends/openmp/packing.py",
line 17, in pack
File
"/home/druiz/.local/lib/python3.4/site-packages/pyfr-0.8.0-py3.4.egg/pyfr/util.py",
line 34, in __call__
File
"/home/druiz/.local/lib/python3.4/site-packages/pyfr-0.8.0-py3.4.egg/pyfr/backends/openmp/provider.py",
line 14, in _build_kernel
File
"/home/druiz/.local/lib/python3.4/site-packages/pyfr-0.8.0-py3.4.egg/pyfr/backends/openmp/compiler.py",
line 42, in function
File
"/home/druiz/.local/lib/python3.4/site-packages/pyfr-0.8.0-py3.4.egg/pyfr/backends/openmp/compiler.py",
line 42, in <listcomp>
File
"/home/druiz/.local/lib/python3.4/site-packages/pyfr-0.8.0-py3.4.egg/pyfr/nputil.py",
line 123, in npdtype_to_ctypestype
KeyError: <class 'numpy.int32'>
After this message, OpenMPI invokes on rank 1 an MPI_ABORT, finishing the
execution. Could this be related with the modifications made before? I also
noticed that he MPI_ABORT is never invoked on the MPI process with rank 0,
not pretty sure if this could help.
Best regards,
-Dani
El jueves, 18 de junio de 2015, 21:37:14 (UTC+2), Freddie Witherden
escribió:
>
> On 18/06/15 20:28, Karl Napf wrote:
> > My uname -n gives
> > Linux ProtonBox 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:31:42 UTC
> > 2014 i686 i686 i686 GNU/Linux
> >
> > Upon comparing np.intp and np.int32 I get the following:
> >
> > Python 3.4.3 |Anaconda 2.2.0 (32-bit)| (default, Jun 4 2015, 15:28:02)
> > [GCC 4.4.7 20120313 (Red Hat 4.4.7-1)] on linux
> > Type "help", "copyright", "credits" or "license" for more information.
> >>>> import numpy as np
> >>>> np
> > <module 'numpy' from
> >
> '/home/tim/python/anaconda3/lib/python3.4/site-packages/numpy/__init__.py'>
> >>>> np.intp
> > <class 'numpy.int32'>
> >>>> np.intp==np.int32
> > False
> >
> > I also tested this with my 64 bit machine at work today and on this
> > architecture, np.intp is indeed equal to np.int64.
> > If I find some time next week I will try out Arvinds fix.
>
> This is a problem that will afflict all 32-bit systems due to a bug in
> numpy. You can reproduce with
>
> import pickle
> import numpy
>
> pickle.dumps([np.intp, np.int32])
>
> At least on x86 systems 32-bit should be avoided on account of it having
> half the number of vector registers compared to 64-bit. This affects
> the performance of both PyFR and the underlying BLAS library.
>
> Regards, Freddie.
>
>
>
--
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.
