numpy isn't linked to any libraries as default.

[terjekv]

After installing numpy via hashstack, the end result is somewhat disappointing:

$ module load FEniCS/1.5.0_2015.02.20_dev
$ python
imPython 2.7.8 (default, Feb 20 2015, 22:02:57) 
[GCC 4.8.2 20140120 (Red Hat 4.8.2-16)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy
>>> numpy.__config__.show()
lapack_info:
  NOT AVAILABLE
lapack_opt_info:
  NOT AVAILABLE
blas_info:
  NOT AVAILABLE
atlas_threads_info:
  NOT AVAILABLE
blas_src_info:
  NOT AVAILABLE
atlas_blas_info:
  NOT AVAILABLE
lapack_src_info:
  NOT AVAILABLE
openblas_info:
  NOT AVAILABLE
atlas_blas_threads_info:
  NOT AVAILABLE
blas_mkl_info:
  NOT AVAILABLE
blas_opt_info:
  NOT AVAILABLE
atlas_info:
  NOT AVAILABLE
lapack_mkl_info:
  NOT AVAILABLE
mkl_info:
  NOT AVAILABLE

This is solvable by editing the yaml file to include the following:

build_stages:

- when: platform == 'linux'
  name: create-site.cfg
  before: install
  handler: bash
  bash: |
    cat > site.cfg << EOF
    [blas]
    blas_libs = blas
    library_dirs = ${ARTIFACT}/lib
    [lapack]
    lapack_libs = lapack
    library_dirs = ${ARTIFACT}/lib
    EOF

But I'm not sure if that's a pretty solution.

[ahmadia]

Hmnn. So you'd like NumPy to use the LAPACK libraries in the same way that SciPy does on Linux? This seems reasonable to me. @certik?

[certik]

I think something along these lines. The current numpy yaml is clearly broken:

extends: [distutils_package]
dependencies:
  build: [blas]
  run: [blas]

sources:
  - key: tar.gz:zzluhi5cjpyt4a3t7lvsicyi4sgrhhtd
    url: http://downloads.sourceforge.net/numpy/numpy-1.8.2.tar.gz

build_stages:

  - when: platform == 'linux'
    name: create-site.cfg
    before: install
    handler: bash
    bash: |
      cat > site.cfg << EOF
      [atlas]
      atlas_libs = openblas
      library_dirs = ${OPENBLAS_DIR}/lib
      EOF

As there is no dependency on openblas in numpy (and even if there was, that's not the way to go). We need to allow numpy to use the lapack implementation that is specified in the profile.

[ahmadia]

Agreed.

[terjekv]

On 12 Mar 2015, at 15:49 , Aron Ahmadia notifications@github.com wrote:

Hmnn. So you'd like NumPy to use the LAPACK libraries in the same way that SciPy does on Linux? This seems reasonable to me. @certik?

Yes, that’d be great. If I understand the SciPy yaml correctly, it also uses the blas / lapack from within hashstack, ensuring that the end build is self-contained and with few external dependencies.

Terje Kvernes
terje@kvernes.no

[mikaem]

Shouldn't numpy/scipy use system optimized blas/lapack whenever possible?

Seems to me that scipy.yaml expects LAPACK_DIR to be set externally:

  build_stages:
    - when: platform == 'linux'
      name: set-lapack-paths
      after: libflags
      before: install
      handler: bash
      bash: |
        export LDFLAGS="$LDFLAGS -shared"
        export ATLAS=$LAPACK_DIR
        export BLAS=$LAPACK_DIR
        export LAPACK=$LAPACK_DIR

and the lapack.yaml only sets LAPACK_LDFLAGS and BLAS_LDFLAGS when_build_dependency:

  when_build_dependency:
    - {set: 'LAPACK_LDFLAGS', value: '-Wl,-rpath,${ARTIFACT}/lib -L${ARTIFACT}/lib -llapack'}
    - {set: 'BLAS_LDFLAGS', value: '-Wl,-rpath,${ARTIFACT}/lib -L${ARTIFACT}/lib -lblas'}

Looks like somebody needs to clean up:-)

[ahmadia]

Configuring NumPy/SciPy is surprisingly challenging. Our normal approach of setting environment variables completely collapses when configuring these libraries: #562 so I've been avoiding tinkering with them too much. That said, if we can figure out how to robustly link in system and hashdist-built lapack/blas libraries, it would be a huge win.

[mikaem]

I know @ahmadia. I just finished installing numpy/scipy on Shaheen, something I probably couldn't have done without this: https://gist.github.com/sanromd/9483946. Thanks:-)

[certik]

@mikaem, the LAPACK_DIR is set automatically by hashdist to point to where the package lapack is installed. The idea is that the user profile can select a system package for lapack, or openblas. But clearly, the details are not very well worked out yet. So for now we concentrated on at least getting the scipy and numpy to build with our own, which also is surprisingly challenging, because numpy and scipy happily pick up systemwide packages sometimes etc. Part of the problem is that that the Python build system is not meant to install Fortran and C libraries as part of the wrappers, only very simple C extensions. However, things can be fixed ---- @mikaem, @terjekv, if you have any tips how we can solve this, that would be awesome. Thanks!

[terjekv]

On 13 Mar 2015, at 04:29 , Ondřej Čertík notifications@github.com wrote:

@mikaem, the LAPACK_DIR is set automatically by hashdist to point to where the package lapack is installed. The idea is that the user profile can select a system package for lapack, or openblas. But clearly, the details are not very well worked out yet. So for now we concentrated on at least getting the scipy and numpy to build with our own, which also is surprisingly challenging, because numpy and scipy happily pick up systemwide packages sometimes etc. Part of the problem is that that the Python build system is not meant to install Fortran and C libraries as part of the wrappers, only very simple C extensions. However, things can be fixed ---- @mikaem, @terjekv, if you have any tips how we can solve this, that would be awesome. Thanks!

To be honest, using LAPACK_DIR sounds like a step in the right direction to me. It’s not ideal but it’s less broken than the current state. :-)

Terje Kvernes
terje@kvernes.no

[dajuno]

Hi there. I'm trying to install numpy via hashstack. I want it to use hashstack's lapack and our optimized system blas. I read the discussion but it's unclear to me how to proceed.
Could somebody please point out the manipulations to the numpy.yaml and environment variables that are necessary?
Thanks a lot.