Jack: If you want to automate testing with the Intel toolchain, https://github.com/nemequ/icc-travis (https://github.com/jeffhammond/icc-travis) has details. I will try to work up a PR...
(there is now sequential and distributed arbitrary-precision SVD via a custom bidiagonal QR algorithm implementation in the style of Demmel and Kahan's hybrid zero-shift approach)
One issue that arises is wrt to the external dependencies, i.e. the patched ParMETIS. The Elemental package depends on this specific version but it would not be proper to just ship the lib in the Elemental package (conflict with i.e. Ubuntu provided ParMETIS package). The cleanest approach would be to package all the dependencies as well and put the constraints for that in the Elemental deb information. All these packages could be pushed to ppa. Any opinions/suggestions how this issue can be resolved?
One constraint is that El depends on an extension of ParMETIS
With that said, most users probably would be fine with just the METIS wrappers
I used to have the ParMETIS extension in El and hooked into the ParMETIS internal API, but that caused its own problems
The nuclear option is to rensme the parmetis symbols
The dependencies I currently use for the package are
set(CPACK_DEBIAN_PACKAGE_DEPENDS "libc6 (>= 2.3.1-6), libgcc1 (>= 1:3.4.2-12), libgomp1, mpich, libmpich-dev, libopenblas-dev, liblapack-dev, python-numpy, libmetis-dev") (for the mpich package)
One remaining test is to check if
libscalapack-mpi-dev is comparable to the version you pull when building Elemental (?).. Are there any other dependencies we are missing?
As for ScaLAPACK: I fixed a bug in their Aggressive Early Deflation Schur decomposition
and this is the one routine Elemental currently makes use of
(though there are wrappers for benchmarking purposes for several other routines)
So depending upon libscalapack-dev is unfortunately not an option
It would be good to have the MPFR and MPC dependencies, as well as QD
(Everything except for the distributed Schur decomposition now supports float, double, DoubleDouble, QuadDouble, Quad, BigFloat, and their complex variants)
I'm in the middle of putting together a Divide and Conquer SVD and can provide guidance but my hands are somewhat full at the moment
Well we dont use that in libSkylark at the moment (asfaik). The question is more what you would like to see in the merge request. Currently we have a package without ParMETIS that works for us (building libSkylark that is) based on 71fce6e65c065e0b2f993435ca7524db7f54fa6f (which is the latest supported version from the libSkylark side)
To facilitate the build process (users, feasible travis-ci build times) we would appreciate an Elemental deb package at the earliest convenience ;)
I can try to come up with a workaround
in fact, it might be disable by default because of lingering bugs
so I would say that using the prepackaged ScaLAPACK lib should be fine as long as it uses a compatible MPI
More reason to package up Elemental I suppose: https://github.com/cvxgrp/cvxpy/issues/288#issuecomment-234671685
Elemental now has a secular equation solver for SVD: https://github.com/elemental/Elemental/blob/fe0c44e809f460dec22c003ea285c68e97a66319/tests/lapack_like/SecularSVD.cpp
@iff conan is not a dependency, it is a package manager for c++, and really a great thing. also, CPack sucks. yes you can create RPM's but no one will accept them to a real repo. You need to write an RPM Spec file or something. That is something you could compose with conan, since conanfile's, rpm spec, and deb package are all very similar. the way to think of conan, is it provides "rpm packages" which do not fix compiler versions or types.
@rhl- super, if you can package Elemental with conan even better. I know CPack has limitations, but its the only thing I know. I simply cannot spend time and dig into conan (or other solutions) to understand the details and package Elemental. Thats why we offered a CPack based solution.
@jack happy to do that, what example do you want? of using spec files? I have plenty: https://rhl.fedorapeople.org/
@iff I am new to conan too, but, I am betting on that technology. CPack is a good start, it generates rpm's that don't pass most basic rpmlint violations. I'm happy to collaborate on this. I think the main thing is not elemental, but all it's dependencies.
I am not a debian packager though.