Dependency on LAPACK 2.0
Is it possible to remove the dependency on LAPACK 2.0, and update ARPACK so that it can use LAPACK 3? I vaguely remember it had to do with the order in which some eigenvalues were returned or something.
I don't dare make this invasive a change to the ARPACK code base. That said, I do have a script by one of the FreeBSD folks that renames the routines in ARPACK's private copy of LAPACK so that you're free to link with LAPACK. This would need to be applied to the codebase. If you have a little time to spend on this, I'd be happy to send you the script and merge the result of your work. Let me know--my email address for this kind of stuff is [email protected].
Andreas
As I understand, simply renaming and linking to the new LAPACK does not solve the problem. Does the script also adjust for the change in behaviour from LAPACK 2.0 to 3.0?
-viral
On Dec 31, 2011, at 12:08 AM, Andreas Klöckner wrote:
I don't dare make this invasive a change to the ARPACK code base. That said, I do have a script by one of the FreeBSD folks that renames the routines in ARPACK's private copy of LAPACK so that you're free to link with LAPACK. This would need to be applied to the codebase. If you have a little time to spend on this, I'd be happy to send you the script and merge the result of your work. Let me know--my email address for this kind of stuff is [email protected].
Andreas
Reply to this email directly or view it on GitHub: https://github.com/inducer/arpack/issues/2#issuecomment-3315819
In what the script implements, ARPACK retains and uses its own private, renamed copy of LAPACK 2. The improvement brought about is that you're not prevented from linking against LAPACK3 for the rest of your code.
Andreas
Yes, I'll be happy to merge it. Do send me the script - [email protected].
I notice that you have removed BLAS/LAPACK from the tree in a commit. Do you keep the subset of LAPACK 2.0 necessary?
Huh, good point. Didn't remember that--it looks like I've been using ARPACK with LAPACK3 with pretty good success then. :)
How do you suggest we resolve this? Do you think you can reinstate the LAPACK 2.0? It's difficult to tell in which cases ARPACK needs LAPACK 2.0, even if it works fine with 3.0. :-)
If you can reinstate LAPACK 2.0 into the build, I can do the merge discussed above. Alternatively, I can do the whole thing, if you can guide me how to do it and prepare a patch.
I'll see what I can do about reinstating LAPACK. BLAS hasn't changed and should be safe to leave external, correct?
Yes, BLAS should be safe to leave external.
-viral
On Jan 1, 2012, at 8:31 PM, Andreas Klöckner wrote:
I'll see what I can do about reinstating LAPACK. BLAS hasn't changed and should be safe to leave external, correct?
Reply to this email directly or view it on GitHub: https://github.com/inducer/arpack/issues/2#issuecomment-3324710
I suspect this is the name mangling patch you were referring to:
http://lists.freebsd.org/pipermail/freebsd-ports-bugs/2011-July/215640.html
Ok -I have added LAPACK 2.0, and mangled the names, and updated the build. See:
https://github.com/JuliaLang/arpack
How do I generate a merge request?