F2PY stopped working with new scipy
Hi I'm using F2PY with the intel fortran compiler under Ubunty Breezy (05.10) AMD64 to wrap some F90 code. If I use the old scipy (package version 0.3.2-2ubuntu1) with: F2PY Version:2.46.243_2020 scipy.distutils Version: 0.3.2 the following test command works as expected: $ f2py --fcompiler=intel -m testmod -c test_data.f90 test_prog.f90 Before I install new scipy, I removed all the f2py files , since it is now included with scipy. I also removed the ubuntu scipy package. After installing numpy-0.9.6 and scipy-0.4.8, trying to generate the wrappers results in the following output: $ f2py --fcompiler=intel -m testmod -c test_data.f90 test_prog.f90 running build running config_fc running build_src building extension "testmod" sources f2py options: [] f2py:> /tmp/tmp_cZX2X/src/testmodmodule.c creating /tmp/tmp_cZX2X creating /tmp/tmp_cZX2X/src Reading fortran codes... Reading file 'test_data.f90' (format:free) Reading file 'test_prog.f90' (format:free) Post-processing... Block: testmod Block: data Block: prog Block: init_data Block: process_data Post-processing (stage 2)... Block: testmod Block: unknown_interface Block: data Block: prog Block: init_data Block: process_data Building modules... Building module "testmod"... Constructing F90 module support for "data"... Variables: test_arr Constructing F90 module support for "prog"... Constructing wrapper function "prog.init_data"... init_data() Constructing wrapper function "prog.process_data"... process_data(factors,[n]) Wrote C/API module "testmod" to file "/tmp/tmp_cZX2X/src/testmodmodule.c" Fortran 90 wrappers are saved to "/tmp/tmp_cZX2X/src/testmod-f2pywrappers2.f90" adding '/tmp/tmp_cZX2X/src/fortranobject.c' to sources. adding '/tmp/tmp_cZX2X/src' to include_dirs. copying /usr/lib/python2.4/site-packages/numpy/f2py/src/fortranobject.c -> /tmp/tmp_cZX2X/src copying /usr/lib/python2.4/site-packages/numpy/f2py/src/fortranobject.h -> /tmp/tmp_cZX2X/src adding '/tmp/tmp_cZX2X/src/testmod-f2pywrappers2.f90' to sources. running build_ext customize UnixCCompiler customize UnixCCompiler using build_ext Could not locate executable efort Could not locate executable efc warning: build_ext: fcompiler=intel is not available. building 'testmod' extension compiling C sources gcc options: '-pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC' creating /tmp/tmp_cZX2X/tmp creating /tmp/tmp_cZX2X/tmp/tmp_cZX2X creating /tmp/tmp_cZX2X/tmp/tmp_cZX2X/src compile options: '-I/tmp/tmp_cZX2X/src -I/usr/lib/python2.4/site-packages/numpy/core/include -I/usr/include/python2.4 -c' gcc: /tmp/tmp_cZX2X/src/fortranobject.c gcc: /tmp/tmp_cZX2X/src/testmodmodule.c Traceback (most recent call last): File "/usr/bin/f2py", line 6, in ? f2py.main() File "/usr/lib/python2.4/site-packages/numpy/f2py/f2py2e.py", line 546, in main run_compile() File "/usr/lib/python2.4/site-packages/numpy/f2py/f2py2e.py", line 533, in run_compile setup(ext_modules = [ext]) File "/usr/lib/python2.4/site-packages/numpy/distutils/core.py", line 85, in setup return old_setup(**new_attr) File "/usr/lib/python2.4/distutils/core.py", line 149, in setup dist.run_commands() File "/usr/lib/python2.4/distutils/dist.py", line 946, in run_commands self.run_command(cmd) File "/usr/lib/python2.4/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/usr/lib/python2.4/distutils/command/build.py", line 112, in run self.run_command(cmd_name) File "/usr/lib/python2.4/distutils/cmd.py", line 333, in run_command self.distribution.run_command(command) File "/usr/lib/python2.4/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/usr/lib/python2.4/site-packages/numpy/distutils/command/build_ext.py", line 109, in run self.build_extensions() File "/usr/lib/python2.4/distutils/command/build_ext.py", line 405, in build_extensions self.build_extension(ext) File "/usr/lib/python2.4/site-packages/numpy/distutils/command/build_ext.py", line 220, in build_extension if self.fcompiler.module_dir_switch is None: AttributeError: 'NoneType' object has no attribute 'module_dir_switch' Is there something wrong with my setup, or what is causing this behaviour? Thanks Neilen -- you know its kind of tragic we live in the new world but we've lost the magic -- Battery 9 (www.battery9.co.za)
Neilen Marais wrote:
Hi
I'm using F2PY with the intel fortran compiler under Ubunty Breezy (05.10) AMD64 to wrap some F90 code. If I use the old scipy (package version 0.3.2-2ubuntu1) with:
F2PY Version:2.46.243_2020 scipy.distutils Version: 0.3.2
the following test command works as expected:
$ f2py --fcompiler=intel -m testmod -c test_data.f90 test_prog.f90
Before I install new scipy, I removed all the f2py files , since it is now included with scipy. I also removed the ubuntu scipy package.
After installing numpy-0.9.6 and scipy-0.4.8, trying to generate the wrappers results in the following output:
$ f2py --fcompiler=intel -m testmod -c test_data.f90 test_prog.f90
adding '/tmp/tmp_cZX2X/src/testmod-f2pywrappers2.f90' to sources. running build_ext customize UnixCCompiler customize UnixCCompiler using build_ext Could not locate executable efort Could not locate executable efc warning: build_ext: fcompiler=intel is not available.
This is the problem. The first thing to check is that efc is on your PATH. The second thing to check is the version string of the compiler. numpy.distutils uses regexes to extract the version of the compiler from the version string. It is possible that you are using a version of the compiler that has a different string than we are expecting. -- Robert Kern robert.kern@gmail.com "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
Hi Robert On Fri, 07 Apr 2006 10:50:47 -0500, Robert Kern wrote:
Neilen Marais wrote:
After installing numpy-0.9.6 and scipy-0.4.8, trying to generate the wrappers results in the following output:
$ f2py --fcompiler=intel -m testmod -c test_data.f90 test_prog.f90
adding '/tmp/tmp_cZX2X/src/testmod-f2pywrappers2.f90' to sources. running build_ext customize UnixCCompiler customize UnixCCompiler using build_ext Could not locate executable efort Could not locate executable efc warning: build_ext: fcompiler=intel is not available.
This is the problem. The first thing to check is that efc is on your PATH. The
efc? AFAIK the official driver name for intel fortran is ifort, and this is indeed on my path. An older name is ifc, though it complains about that command name being deprecated: brick@genugtig:/usr/local/src/numpy-0.9.6 $ ifc ifc: warning: The Intel Fortran driver is now named ifort. You can suppress this message with '-quiet' ifort: Command line error: no files specified; for help type "ifort -help" brick@genugtig:/usr/local/src/numpy-0.9.6 $ efc bash: efc: command not found brick@genugtig:/usr/local/src/numpy-0.9.6 $ ifort -v Version 9.0 brick@genugtig:/usr/local/src/numpy-0.9.6 I also added symbolic links for efc and efort. Still no-go though.
second thing to check is the version string of the compiler. numpy.distutils uses regexes to extract the version of the compiler from the version string. It is possible that you are using a version of the compiler that has a different string than we are expecting.
How can I obtain this test string? It did work with the older version of scipy/f2py, so this may be some sort of regression. Thanks Neilen -- you know its kind of tragic we live in the new world but we've lost the magic -- Battery 9 (www.battery9.co.za)
Neilen Marais wrote:
Hi Robert
On Fri, 07 Apr 2006 10:50:47 -0500, Robert Kern wrote:
Neilen Marais wrote:
After installing numpy-0.9.6 and scipy-0.4.8, trying to generate the wrappers results in the following output:
$ f2py --fcompiler=intel -m testmod -c test_data.f90 test_prog.f90
adding '/tmp/tmp_cZX2X/src/testmod-f2pywrappers2.f90' to sources. running build_ext customize UnixCCompiler customize UnixCCompiler using build_ext Could not locate executable efort Could not locate executable efc warning: build_ext: fcompiler=intel is not available.
This is the problem. The first thing to check is that efc is on your PATH. The
efc? AFAIK the official driver name for intel fortran is ifort, and this is indeed on my path.
Well, according to the error message, it was looking for efort and efc for some reason. Looking at the code (numpy/distutils/fcompiler/intel.py), it appears that the IntelItaniamFCompiler class looks for efort and efc; however, that compiler is supposed to be specified by intele, not intel.
An older name is ifc, though it complains about that command name being deprecated:
brick@genugtig:/usr/local/src/numpy-0.9.6 $ ifc ifc: warning: The Intel Fortran driver is now named ifort. You can suppress this message with '-quiet' ifort: Command line error: no files specified; for help type "ifort -help"
brick@genugtig:/usr/local/src/numpy-0.9.6 $ efc bash: efc: command not found
brick@genugtig:/usr/local/src/numpy-0.9.6 $ ifort -v Version 9.0
brick@genugtig:/usr/local/src/numpy-0.9.6
I also added symbolic links for efc and efort. Still no-go though.
second thing to check is the version string of the compiler. numpy.distutils uses regexes to extract the version of the compiler from the version string. It is possible that you are using a version of the compiler that has a different string than we are expecting.
How can I obtain this test string? It did work with the older version of scipy/f2py, so this may be some sort of regression.
The regexes are the version_pattern class attributes in the file intel.py given above. -- Robert Kern robert.kern@gmail.com "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
A question on the (terrific!) ndimage module: Is the LOG operator (laplace of gauss) == scipy.ndimage.gaussian_laplace? Is the DOG operator (difference of Gaussians) already implemented in ndimage or have I just overlooked it? # A snippet on how to compute efficiently difference of Gaussians would # greatly appreciated... -jelle
Hi On Mon, 10 Apr 2006 11:45:32 -0500, Robert Kern wrote:
Neilen Marais wrote:
Hi Robert
On Fri, 07 Apr 2006 10:50:47 -0500, Robert Kern wrote:
Well, according to the error message, it was looking for efort and efc for some reason. Looking at the code (numpy/distutils/fcompiler/intel.py), it appears that the IntelItaniamFCompiler class looks for efort and efc; however, that compiler is supposed to be specified by intele, not intel.
It seems to be confused by the fact that I'm using the EM64T version of the intel compilers. The version string printed by my compiler is: Intel(R) Fortran Compiler for Intel(R) EM64T-based applications, Version 9.0 Build 20050430 Package ID: l_fc_p_9.0.021
How can I obtain this test string? It did work with the older version of scipy/f2py, so this may be some sort of regression.
The regexes are the version_pattern class attributes in the file intel.py given above.
I updated this regex, and also commented out some options that aren't valid for the EM64T compiler. A diff on intel.py from today's svn reveals: --- intel.py~ 2006-04-12 18:34:30.000000000 +0200 +++ intel.py 2006-04-20 12:39:01.000000000 +0200 @@ -10,7 +10,7 @@ class IntelFCompiler(FCompiler): compiler_type = 'intel' - version_pattern = r'Intel\(R\) Fortran Compiler for 32-bit '\ + version_pattern = r'Intel\(R\) Fortran Compiler for .* '\ 'applications, Version (?P<version>[^\s*]*)' for fc_exe in map(find_executable,['ifort','ifc']): @@ -56,12 +56,12 @@ opt.append('-tpp5') elif cpu.is_PentiumIV() or cpu.is_Xeon(): opt.extend(['-tpp7','-xW']) - if cpu.has_mmx() and not cpu.is_Xeon(): - opt.append('-xM') - if cpu.has_sse2(): - opt.append('-arch SSE2') - elif cpu.has_sse(): - opt.append('-arch SSE') +# if cpu.has_mmx() and not cpu.is_Xeon(): +# opt.append('-xM') +# if cpu.has_sse2(): +# opt.append('-arch SSE2') +# elif cpu.has_sse(): +# opt.append('-arch SSE') return opt def get_flags_linker_so(self): This gets the compiler to run, and builds the extension module. The resulting module doesn't quite work right though. I'll make a separate post about that though. Of course these changes may break things for 32-bit platforms. Cheers Neilen -- you know its kind of tragic we live in the new world but we've lost the magic -- Battery 9 (www.battery9.co.za)
Hi Again On Thu, 20 Apr 2006 19:36:15 +0200, Neilen Marais wrote:
How can I obtain this test string? It did work with the older version of scipy/f2py, so this may be some sort of regression.
The regexes are the version_pattern class attributes in the file intel.py given above.
I updated this regex, and also commented out some options that aren't valid for the EM64T compiler. A diff on intel.py from today's svn reveals:
Actually, I just looked in the old scipy distutils, and the regexps are exactly the same as in numpy! Strange that it worked before, unless it's a bug in the old distutils code that it ignored the test? Cheers Neilen
participants (3)
-
Jelle Feringa / EZCT Architecture & Design Research -
Neilen Marais -
Robert Kern