Re: [pyfrmailinglist] OpenMP backend error
Hi Emre, On 31/03/2016 17:24, emre wrote: > I have a similar problem. > > I installed Anaconda distribution, therefore I am not sure about the > compiler but mpi4py seems to work only with Intel MPI. At first it was > installing using MS MPI with wrong directories, then I corrected them > with correct MS MPI. But the result of famous mpiexec -4 hello.py was > always 0. Then I tried with Intel MPI and it worked. I validated this > behaviour with VS Intel Fortran and the result was the same. When I run > mpiexec --version command I get Intel. > > > Please find attached the log files produced when I ran the Couette example. It is possible that the arguments for ICC on Windows are different to those used by ICC on Linux. You should try compiling a simple piece of C code with the arguments show in the error message to see if this works (and if not, what needs to be changed for it to work). > > Also could you tell me if Cblas directory is accepted or not, please? I > do not know the execution order, so I cannot say if it is accepted or not. I am not sure exactly what you mean by Cblas directory? The cblas key should have a value which is the path to a suitable cblas implementation on your system (Intel MKL, ATLAS, OpenBLAS). Regards, Freddie. 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 pyfrmailinglist+unsubscr...@googlegroups.com. To post to this group, send an email to pyfrmailinglist@googlegroups.com. Visit this group at https://groups.google.com/group/pyfrmailinglist. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [pyfrmailinglist] OpenMP backend error
Hi Freddie,
I have a similar problem.
I installed Anaconda distribution, therefore I am not sure about the
compiler but mpi4py seems to work only with Intel MPI. At first it was
installing using MS MPI with wrong directories, then I corrected them with
correct MS MPI. But the result of famous mpiexec -4 hello.py was always 0.
Then I tried with Intel MPI and it worked. I validated this behaviour with
VS Intel Fortran and the result was the same. When I run mpiexec --version
command I get Intel.
Please find attached the log files produced when I ran the Couette example.
Also could you tell me if Cblas directory is accepted or not, please? I do
not know the execution order, so I cannot say if it is accepted or not.
Thank you,
I wish you a nice day,
Cheers,
Emre
29 Şubat 2016 Pazartesi 22:36:16 UTC+2 tarihinde Freddie Witherden yazdı:
>
> Hi Leo,
>
> On 25/02/16 17:16, 'Leo Allen' via PyFR Mailing List wrote:
> > Traceback (most recent call last):
> > File "/home/User/PyFR/env4/bin/pyfr", line 9, in
> > load_entry_point('pyfr==1.3.0', 'console_scripts', 'pyfr')()
> > File "/home/User/PyFR/env4/src/pyfr/pyfr/scripts/main.py", line 109,
> > in main
> > args.process(args)
> > File "/home/User/PyFR/env4/src/pyfr/pyfr/scripts/main.py", line 230,
> > in process_run
> > args, NativeReader(args.mesh), None, Inifile.load(args.cfg)
> > File "/home/User/PyFR/env4/src/pyfr/pyfr/scripts/main.py", line 214,
> > in _process_common
> > solver = get_solver(backend, rallocs, mesh, soln, cfg)
> > File "/home/User/PyFR/env4/src/pyfr/pyfr/solvers/__init__.py", line
> > 14, in get_solver
> > return get_integrator(backend, systemcls, rallocs, mesh, initsoln,
> cfg)
> > File "/home/User/PyFR/env4/src/pyfr/pyfr/integrators/__init__.py",
> > line 26, in get_integrator
> > return integrator(backend, systemcls, rallocs, mesh, initsoln, cfg)
> > File "/home/User/PyFR/env4/src/pyfr/pyfr/integrators/controllers.py",
> > line 14, in __init__
> > super().__init__(*args, **kwargs)
> > File "/home/User/PyFR/env4/src/pyfr/pyfr/integrators/steppers.py",
> > line 9, in __init__
> > super().__init__(*args, **kwargs)
> > File "/home/User/PyFR/env4/src/pyfr/pyfr/integrators/base.py", line
> > 41, in __init__
> > self.system = systemcls(backend, rallocs, mesh, initsoln, nreg, cfg)
> > File "/home/User/PyFR/env4/src/pyfr/pyfr/solvers/base/system.py", line
> > 59, in __init__
> > self._gen_kernels(eles, int_inters, mpi_inters, bc_inters)
> > File "/home/User/PyFR/env4/src/pyfr/pyfr/solvers/base/system.py", line
> > 167, in _gen_kernels
> > kernels[pn, kn].append(kgetter())
> > File "/home/User/PyFR/env4/src/pyfr/pyfr/solvers/euler/elements.py",
> > line 70, in
> > f=self._vect_upts
> > File "/home/User/PyFR/env4/src/pyfr/pyfr/backends/base/backend.py",
> > line 154, in kernel
> > return kern(*args, **kwargs)
> > File "/home/User/PyFR/env4/src/pyfr/pyfr/backends/base/kernels.py",
> > line 162, in kernel_meth
> > fun = self._build_kernel(name, src, list(it.chain(*argt)))
> > File "/home/User/PyFR/env4/src/pyfr/pyfr/util.py", line 34, in
> __call__
> > res = cache[key] = self.func(*args, **kwargs)
> > File "/home/User/PyFR/env4/src/pyfr/pyfr/backends/openmp/provider.py",
> > line 13, in _build_kernel
> > mod = GccSourceModule(src, self.backend.cfg)
> > File "/home/User/PyFR/env4/src/pyfr/pyfr/backends/openmp/compiler.py",
> > line 61, in __init__
> > super().__init__(src, cfg)
> > File "/home/User/PyFR/env4/src/pyfr/pyfr/backends/openmp/compiler.py",
> > line 30, in __init__
> > lname = self._build(tmpdir)
> > File "/home/User/PyFR/env4/src/pyfr/pyfr/backends/openmp/compiler.py",
> > line 80, in _build
> > call_capture_output(cmd + self._cflags, cwd=tmpdir)
> > File
> > "/home/User/PyFR/env4/lib/python3.4/site-packages/pytools/prefork.py",
> > line 197, in call_capture_output
> > return forker[0].call_capture_output(cmdline, cwd, error_on_nonzero)
> > File
> > "/home/User/PyFR/env4/lib/python3.4/site-packages/pytools/prefork.py",
> > line 54, in call_capture_output
> > % ( " ".join(cmdline), e))
> > pytools.prefork.ExecError: error invoking 'gcc -shared -std=c99 -Ofast
> > -march=native -fopenmp -fPIC -o libtmp.so tmp.c': [Errno 11] Resource
> > temporarily unavailable
>
> Here is your error. Cygwin does not seem to be able to correctly
> emulate the position independent nature of shared libraries that is
> required by the C/OpenMP backend. Instead it appears to have to rebase
> .so's (much like Windows usually does with .dll's) with the shared
> libraries themselves being position dependent.
>
> The need to explicitly rebase shared libraries does not chime well with
> dynamic compilation approached used by PyFR.
>
> It is quite possibly less work to get the C/OpenMP backend working
> natively with Microsoft Windows than it
Re: [pyfrmailinglist] OpenMP backend error
Hi Freddie,
After commenting out the prefork enabling, I made the following changes to
util.py on the call function, from line 21.
def __call__(self, *args, **kwargs):
instance = args[0]
print("")
print(self)
print("--self")
print(*args)
print("--args")
print(**kwargs)
print("--kwargs")
print("")
try:
cache = instance._memoize_cache
except AttributeError:
cache = instance._memoize_cache = {}
key = (self.func, pickle.dumps(args[1:]), pickle.dumps(kwargs))
try:
res = cache[key]
print(res)
print("res cache key good")
except KeyError:
res = cache[key] = self.func(*args, **kwargs)
print("res cache key bad")
print(res)
print("new res cache key")
return res
I did this so that the shell would print out the arguments being applied,
and that may indicate what is causing the error. The result came out to
this: http://pastebin.com/pjJSKP8m
One line that did stand out was this one, at 1165:
0 [main] python3 4796 child_info_fork::abort: unable to remap
libtmp.so to same address as parent (0x1F) - try running rebaseall
which may be problematic since those are tmp files, and I ran rebaseall
just to be safe, but I had the same error afterwards.
Would you say that this is an OS error? I'm wondering if this can be
patched with a small amount of code, but if this is beyond your realm then
that's fair enough, I'll try looking elsewhere for solutions.
I hope to hear back from you soon.
Kind Regards,
Leo Allen
--
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 pyfrmailinglist+unsubscr...@googlegroups.com.
To post to this group, send an email to pyfrmailinglist@googlegroups.com.
Visit this group at https://groups.google.com/group/pyfrmailinglist.
For more options, visit https://groups.google.com/d/optout.
Re: [pyfrmailinglist] OpenMP backend error
Hi Leo, On 24/02/16 16:17, 'Leo Allen' via PyFR Mailing List wrote: > Hello, I've been using PyFR on a windows laptop with Cygwin 64bit, and > after upgrading pyfr to 1.3, I get an error which seems to persist even > when I downgrade back to 1.2. Nothing substantial changed between v1.2.0 and v1.3.0 with regards to the OpenMP backend. It is extremely likely that this error is due to either a new version of pytools or Cygwin. Given you are running on a laptop your best bet is to comment out the enable_prefork() line on: https://github.com/vincentlab/PyFR/blob/develop/pyfr/scripts/main.py#L196 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 pyfrmailinglist+unsubscr...@googlegroups.com. To post to this group, send an email to pyfrmailinglist@googlegroups.com. Visit this group at https://groups.google.com/group/pyfrmailinglist. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
