Dear Maintainer,

I am a long time NWChem (ab)user.  I always have to compile NWChem myself,
instead of using the binary version provided by debian, because for large
enough molecules matrices become too big for the 32 bit int interface, and
only run if NWChem was compiled with a 64 bit int lapack/blas.
I understand the need to provide a version of NWChem in debian that works
with free libs available in debian as well, hence the need (so far) to
compile it using the 64 to 32 bit conversion of ints on 64 bit machines.
However, lapack and blas libs with 64 bit integer interfaces just appeared
on debian experimental, and have been available for some time in the
non-free (but packaged in non-free) Intel MKL libs.
Apparently, this would require limited changes in the debian/rules file.
Would you consider building (also) such a version of nwchem, compiled with
long int blas/lapack libs? If you want to retain the current version, it
could be a conflicting package with a slightly different name.
Here are the environment variable definitions that would need to be included:

export BLAS_SIZE=8
export BLAS_LIB=-lmkl_blas95_ilp64 -Wl,--start-group -lmkl_gf_ilp64 -lmkl_intel_thread -lmkl_core -Wl,--end-group -liomp5 -lpthread -lm -ldl
export LAPACK_SIZE=8
export LAPACK_LIB=-lmkl_blas95_ilp64 -lmkl_lapack95_ilp64 -Wl,--start-group -lmkl_gf_ilp64 -lmkl_intel_thread -lmkl_core -Wl,--end-group -liomp5 -lpthread -lm -ldl
export USE_SCALAPACK=yes
export SCALAPACK_SIZE=8
export SCALAPACK_LIB=-lmkl_blas95_ilp64 -lmkl_lapack95_ilp64 -lmkl_scalapack_ilp64 -Wl,--start-group -lmkl_gf_ilp64 -lmkl_intel_thread -lmkl_core -lmkl_blacs_openmpi_ilp64 -Wl,--end-group -liomp5 -lpthread -lm -ldl
export SCALAPACK=-lmkl_blas95_ilp64 -lmkl_lapack95_ilp64 -lmkl_scalapack_ilp64 -Wl,--start-group -lmkl_gf_ilp64 -lmkl_intel_thread -lmkl_core -lmkl_blacs_openmpi_ilp64 -Wl,--end-group -liomp5 -lpthread -lm -ldl
export HAS_BLAS="yes"
export BLASOPT="-lmkl_blas95_ilp64 -lmkl_lapack95_ilp64 -lmkl_scalapack_ilp64 -Wl,--start-group -lmkl_gf_ilp64 -lmkl_intel_thread -lmkl_core -lmkl_blacs_openmpi_ilp64 -Wl,--end-group -liomp5 -lpthread -lm -ldl"
export BLACS=$(SCALAPACK)

and "make 64_to_32" and "make 32_to_64" would have to be commented out.

The libglobalarrays-dev package would also need to be compiled with the
same lapack/blas/scalapack libs and int sizes (requiring 3 lines to be
edited in the corresponding debian/rules).

Of course, I would be willing to help, even if I am not an official
Debian Developer.

Thanks in advance, best regards
Giacomo Mulas

Hi Giacomo,

sorry, I apparently missed your mail initially.

I don't follow it closely, are you saying that both the refblas/lapack
packages now provide a 64bit int interface, and MKL? Or just MKL?

Unless there are considerable downsides (are there?) I would not mind
switching the nwchem packaging to a 64bit int build using blas/lapack
libraries from main.

Regarding mkl, my current, initial opinion is that we would welcome
patches to make it possible to rebuild nwchem for MKL without source
changes (via some DEB_BUILD_OPTIONS or other external flags), but
building nwchem twice and once for MKL would (I believe) mean the source
package would have to move into contrib as it build-depended on a
non-free package.

Does anybody else want to chime in here and offer their opinion?


Michael

Hi NWChem maintainers,

blas/lapack lib maintainer here.

both. We additionally compiled a 64bit-indexing version of src:lapack,
namely libblas64-dev and liblapack64-dev.

Once built against the standard implementaiton, users could switch
the underlying blas64/lapack64 with the update-alternatives mechanism.
https://wiki.debian.org/DebianScience/LinearAlgebraLibraries

e.g libopenblas64-0 (still in exp), libblis64-2,
libmkl-rt (need to export MKL_INTERFACE_LAYER=ILP64 when actually using)

However I don't recommend compiling debian packages with the
  -lmkl_gf_ilp64 -lmkl_intel_thread -lmkl_core -lmkl_blacs_openmpi_ilp64 ...
way as it would drive the package into contrib.

There is no known downside for the 32-bit indexing to 64-bit one switch.
According to the user demand, I think keeping a 32-bit indexing version
would not be quite useful, as the same functionality has been delivered
by the 64bit version.

as explained above.

Hi,

Cool, thanks for the explanation.

If somebody (Giacomo?) wants to come up with patches to switch NWChem
over to 64bit Blas, that'd be great. I'm pretty busy right now and won't
have time for a while to look into it myself.


Michael