Le lundi 22 décembre 2014 à 07:23 -0800, Andrei Berceanu a écrit : > Hi guys, > > The issue persists on my arch box, and converting the matrix from > sparse to dense takes up too much memory. Are there any temporary > workarounds, while waiting for the upstream fix? The bug seems to be in Arch rather than in Julia. Have you tried to file an issue there?
Sorry, I don't know a workaround, but you may use the generic Linux build instead of the Arch package in the meantime. Regards > Thanks, > A > > On Thursday, December 18, 2014 1:58:52 AM UTC+1, Valentin Churavy > wrote: > There is an AUR pkgbuild, but since Julia is in community we > can not depend on that. But yeah the system BLAS seems to be > at fault. I added the Arch maintainer of Julia to the > conversation. > > > @Alexander. > There seems to be an issue with the BLAS implementation for > Julia. Would it be possible to use OpenBLAS either via moving > the pkgbuild from the aur to community or build Julia with > USE_SYSTEM_BLAS=0? > > > > On Wednesday, 17 December 2014 23:26:54 UTC+1, Tony Kelman > wrote: > Might be a good idea to package OpenBLAS for Arch, if > you can't find an existing PKGBUILD. > > > On Tuesday, December 16, 2014 2:22:10 PM UTC-8, Milan > Bouchet-Valat wrote: > Le mardi 16 décembre 2014 à 13:27 -0800, > Elliot Saba a écrit : > > I think the problem here is that we might be > using something that > > requires a certain version of BLAS or > LAPACK, or possibly a patched > > LAPACK or something. We get a patched > LAPACK when we build OpenBLAS. > > I've directly included Andreas in this > reply, as he's the kind of guy > > that would have a good idea as to what's > going on here. > I don't think Julia needs a patched LAPACK, at > least it builds fine on > Fedora with the system's LAPACK. It's the one > from OpenBLAS, not the > reference LAPACK, but it worked fine too with > Julia 0.3.0 when I used > the latter (though it was slower). > > FWIW the Fedora package sets USE_SYSTEM_*=1 > for everything, except > libuv, Rmath and libm. Additional flags are > LIBBLAS=-lopenblasp > LIBBLASNAME=libopenblasp.so.0 > LIBLAPACK=-lopenblasp > LIBLAPACKNAME=libopenblasp.so.0 USE_BLAS64=0 > > Maybe using Julia's version of SuiteSparse > together with the system > BLAS/LAPACK does not work? > > > Also, do you imply it worked fine with 0.3.2, > and started randomly > failing only with 0.3.3? > > > Regards > > > > On Tue, Dec 16, 2014 at 10:03 AM, Valentin > Churavy > > <[email protected]> wrote: > > So I narrowed it down to combining > the system's blas with > > Julia's suitesparse. In the tests I > made laplack has no > > influence. Should I file an issue > against Julia or with the > > Archlinux package? What are the > Fedora packages bundling? > > > > > > USE_SYSTEM_BLAS=1 \ > > USE_SYSTEM_SUITESPARSE=0 \ > > > > > > On Tuesday, 16 December 2014 > 18:07:23 UTC+1, Valentin Churavy > > wrote: > > Ok setting > > USE_SYSTEM_BLAS=0 \ > > USE_SYSTEM_LAPACK=0 \ > > USE_SYSTEM_SUITESPARSE=0 \ > > > > Make the problem go away. So > it is the interaction > > between the system > blas/lapack and the built > > suitesparese. Are there any > patches that julia carries > > over suitesparse 4.4.1? > > > > > > On Tuesday, 16 December 2014 > 17:28:28 UTC+1, Valentin > > Churavy wrote: > > So using > > > > > > make \ > > > USE_SYSTEM_LLVM=0 \ > > > USE_SYSTEM_LIBUNWIND=1 \ > > > USE_SYSTEM_READLINE=0 \ > > > USE_SYSTEM_PCRE=1 \ > > > USE_SYSTEM_LIBM=1 \ > > > USE_SYSTEM_OPENLIBM=0 \ > > > USE_SYSTEM_OPENSPECFUN=0 \ > > > USE_SYSTEM_BLAS=1 \ > > > USE_SYSTEM_LAPACK=1 \ > > > USE_SYSTEM_FFTW=1 \ > > USE_SYSTEM_GMP=1 > \ > > > USE_SYSTEM_MPFR=1 \ > > > USE_SYSTEM_ARPACK=1 \ > > > USE_SYSTEM_SUITESPARSE=0 \ > > > USE_SYSTEM_ZLIB=1 \ > > > USE_SYSTEM_GRISU=0 \ > > > USE_SYSTEM_RMATH=0 \ > > > USE_SYSTEM_LIBUV=0 \ > > > USE_SYSTEM_UTF8PROC=0 \ > > USE_MKL=0 \ > > USE_BLAS64=0 \ > > > USE_LLVM_SHLIB=0 > > > > > > leads to the error > observed by me and Andrei, > > can anybody not > using Arch try that out? > > > > On Tuesday, 16 > December 2014 17:07:55 UTC+1, > > Valentin Churavy > wrote: > > So building > it from the PKGBUILD leads > > to the same > error. I am now building > > it with the > same make options from the > > tar.gz on > the Julia download page. > > > > > > Andrei we > probably have to build other > > parts that > interact with suitesparse > > from source > instead of using the Arch > > ones. But if > the problem persists > > while using > the tarball, then at least > > other people > on non-Arch distros can > > try to see > if it works for them and > > which > interaction leads to the error. > > > > > > For the time > being you can call > > full(A) on > your sparse matrix to > > convert it > to a dense matrix and > > circumvent > the problem > > > > On Tuesday, > 16 December 2014 16:52:18 > > UTC+1, > Andrei Berceanu wrote: > > So > if your suspicion is > > > correct, setting > > > USE_SYSTEM_SUITESPARSE=1 > > > should fix this, right? > > Let > me know how it goes :) > > > > On > Tuesday, December 16, 2014 > > > 3:19:43 PM UTC+1, Valentin > > > Churavy wrote: > > > So your system setup > > > is exactly the same > > > (except me running on > > > CPU: Intel(R) Core(TM) > > > i5-2520M CPU @ > > > 2.50GHz) and I can > > > conform that the > > > following code > > > > > > > > > A = sparse([rand() + > > > rand() * im for i in > > > 1:100, j in 1:100]) > > > B = [rand() + rand() > > > * im for i in 1:100] > > > A\B > > > > > > > > > leads to the following > > > error: > > > julia: symbol lookup > > > error: /usr/bin/../lib/julia/libcholmod.so: > undefined symbol: zpotrf_ > > > > > > > > > pacman > > > -Qo /usr/lib/libcholmod.so > > > /usr/lib/libcholmod.so > > > is owned by > > > suitesparse 4.4.1-1 > > > > > > > > > but the PKGBUILD > > > at > > https://projects.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/julia > tells me that the Julia package was build with USE_SYSTEM_SUITESPARSE=0 > > > > > > > > > I am currently > > > building the Julia > > > from the PKGBUILD in > > > order to confirm that > > > these build-options > > > lead to the problem. > > > > > > > > > Best, > > > Valentin > > > > > > On Tuesday, 16 > > > December 2014 11:59:51 > > > UTC+1, Andrei Berceanu > > > wrote: > > > I now have a > > > more accurate > > > description of > > > when the error > > > happens. If I > > > try to solve > > > the following > > > linear system > > > > > > A > > > 1681x1681 sparse matrix with 8321 > Complex{Float64} entries: > > > [1 , 1] = -10.95 > +0.001im > > > [2 , 1] = > 0.415415-0.909632im > > > [42 , 1] = 1.0 > +0.0im > > > [1 , 2] = 0.415415 > +0.909632im > > > [2 , 2] = -10.56 > +0.001im > > > [3 , 2] = > 0.415415-0.909632im > > > [43 , 2] = 1.0 > +0.0im > > > [2 , 3] = 0.415415 > +0.909632im > > > [3 , 3] = -10.19 > +0.001im > > > [4 , 3] = > 0.415415-0.909632im > > > ⋮ > > > [1638, 1679] = 1.0 > +0.0im > > > [1678, 1679] = > 0.415415-0.909632im > > > [1679, 1679] = -10.19 > +0.001im > > > [1680, 1679] = 0.415415 > +0.909632im > > > [1639, 1680] = 1.0 > +0.0im > > > [1679, 1680] = > 0.415415-0.909632im > > > [1680, 1680] = -10.56 > +0.001im > > > [1681, 1680] = 0.415415 > +0.909632im > > > [1640, 1681] = 1.0 > +0.0im > > > [1680, 1681] = > 0.415415-0.909632im > > > [1681, 1681] = -10.95 > +0.001im > > > > > > B > > > 1681-element Array{Complex{Float64},1}: > > > 0.525444+0.850828im > > > 0.644642+0.764485im > > > -0.658926-0.752208im > > > -0.653119+0.757256im > > > -0.684803+0.728728im > > > 0.499568-0.866275im > > > -0.362176-0.93211im > > > 0.87001+0.493034im > > > -0.616929-0.787019im > > > 0.698366-0.715741im > > > -0.275131-0.961407im > > > -0.984546-0.175127im > > > -0.857186+0.515007im > > > ⋮ > > > -0.148487-0.988914im > > > 0.860544-0.509376im > > > -0.929042+0.369975im > > > -0.812528-0.582923im > > > -0.972683-0.232138im > > > -0.449449+0.893306im > > > -0.929623-0.368512im > > > 0.950785+0.309852im > > > -0.309421-0.950925im > > > 0.115447+0.993314im > > > 0.685855+0.727738im > > > -0.215699+0.97646im > > > > > > A\B > > > julia: symbol > > > ...
