Bug#935994: [Debichem-devel] Bug#935994: nwchem: NWChem compiled with long int lapack/blas interface?
Hi, On Thu, Oct 31, 2019 at 01:35:00AM +, Mo Zhou wrote: > Hi NWChem maintainers, > > blas/lapack lib maintainer here. > > > 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? > > 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. 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
Bug#935994: [Debichem-devel] Bug#935994: nwchem: NWChem compiled with long int lapack/blas interface?
Hi NWChem maintainers, blas/lapack lib maintainer here. > 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? 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. > 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. 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. > 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. as explained above.
Bug#935994: [Debichem-devel] Bug#935994: nwchem: NWChem compiled with long int lapack/blas interface?
Hi Giacomo, sorry, I apparently missed your mail initially. On Wed, Aug 28, 2019 at 08:42:21PM +0200, Giacomo Mulas wrote: > 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. 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? > 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? 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
