Re: [OPM] Umfpack runtime dependendy is problematic
Bård Skaflestad wrote I don't know enough about linkers to address any of these points, but I do recall that someone (Markus?) pointed out on that at least on supercomputers, the (startup) cost of the dynamic linker resolving symbols is considerable. I haven't formed an opinion on what to do yet, so I'm soliciting input and (informed) opinions on the costs and benefits of static vs. dynamic linking by default. Bård ___ Opm mailing list Opm@opm-project.org http://www.opm-project.org/mailman/listinfo/opm Hi, Yes that was me. The problem was that on that machine each node loaded the library at the same time from a network file system. Did scale that well. Markus -- Dr. Markus Blatt - HPC-Simulation-Software Services Hans-Bunte-Str. 8-10, 69123 Heidelberg, Germany Tel. +49 (0)160 97590858 Fax +49 (0)322 1108991658 ___ Opm mailing list Opm@opm-project.org http://www.opm-project.org/mailman/listinfo/opm
Re: [OPM] Umfpack runtime dependendy is problematic
On 2013-10-10 08:40, Alf Birger Rustad wrote: The most convenient one being that suitesparse is installed by default over here. Unfortunately, that may be difficult to achieve Assuming that the cluster is running RHEL5 and a mainstream architecture like x86_64, I would like point out that package suitesparse is in EPEL. If the IT department has problems installing it on a computation cluster, then IMO that's a problem on its own. The second being that we maintain the suitesparse libraries out of tree, pointing to them with LD_LIBRARY_PATH. On 2013-10-10 08:49, Joakim Hove wrote: I though opm made quite extensive use of RPATH, and then the library will be found runtime as long as we have it installed somewhere On 2013-10-10 08:56, Alf Birger Rustad wrote: The development packages for suitesparse is installed on build nodes the ordinary way, so RPATH will not do any good here unless we install and maintain the dev packages out-of-tree too. I think (with a fair degree of certainty) that what Joakim meant is that you could install suitesparse (the runtime) in at the same location on the build nodes as it would be on the computation nodes, and then the RPATH encoded in the library would make it be picked up without setting LD_LIBRARY_PATH. The third option is to compile umfpack with dependency (libamd.so on AMD systems I believe) statically. If you pass -Dumfpack_LIBRARY=/foo/UMFPACK/Lib/libumfpack.a I think it should work as intended; otherwise it is a regular bug issue. The fourth option is to remove the dependency on umfpack (didn’t it use to be an optional dependency?), not sure about the implications I think Arne Morten needs it to do multi-threading (or rather, that UMFPACK is the alternative that can co-existing with reasonable multi-threading). -- Roland. ___ Opm mailing list Opm@opm-project.org http://www.opm-project.org/mailman/listinfo/opm
Re: [OPM] Umfpack runtime dependendy is problematic
If you pass -Dumfpack_LIBRARY=/foo/UMFPACK/Lib/libumfpack.a I think it should work as intended; otherwise it is a regular bug issue. That will make our build script slightly more involved, but should work. It will however not work for the next user who wants to kick the tires of OPM (in the sense that the binaries will fail by default until the user figures out a solution like this one). I think Arne Morten needs it to do multi-threading (or rather, that UMFPACK is the alternative that can co-existing with reasonable multi-threading). Arne Morten, maybe you can chime in here. Is this a stop gap solution, or a more permanent situation? Thanks clearing up my misunderstanding of the AMD lib BTW, I just assumed it was related to CPU optimizations. Please consider being more verbose too ;) i consider anything that does not follow standardized procedures to be a stop gap solution, cause it will almost certainly break sooner or later. you refuse (are unable to) follow standardized procedures, and thus you will have to deal with breakage. this sounds like a decent workable hack. arnem ___ Opm mailing list Opm@opm-project.org http://www.opm-project.org/mailman/listinfo/opm
Re: [OPM] Umfpack runtime dependendy is problematic
i consider anything that does not follow standardized procedures to be a stop gap solution, cause it will almost certainly break sooner or later. you refuse (are unable to) follow standardized procedures, and thus you will have to deal with breakage. this sounds like a decent workable hack. arnem Again you are too short for me to understand what you mean. Let me try to rephrase, is umfpack a dependency we need to handle in the long run, or are you using it temporarily to circumvent threading shortcomings in superlu? BTW, standardized procedures is not necessarily a well-defined concept ;) Generally speaking, I would suggest static linking by default of any runtime library dependency not supported by Red Hat. That is the recommendation of LSB, no bonus points for guessing what the S stands for. Cheers, Alf --- The information contained in this message may be CONFIDENTIAL and is intended for the addressee only. Any unauthorised use, dissemination of the information or copying of this message is prohibited. If you are not the addressee, please notify the sender immediately by return e-mail and delete this message. Thank you ___ Opm mailing list Opm@opm-project.org http://www.opm-project.org/mailman/listinfo/opm
Re: [OPM] Umfpack runtime dependendy is problematic
On Thursday 10 October 2013 14:39:24 Alf Birger Rustad wrote: Generally speaking, I support dynamic linking where libs are available (which includes blas and lapack). Simply because I believe it is less error prone since it is the standard modulo of operandi for GNU/Linux distributions (I do agree on that Arne Morten). I agree insofar that it is advisable to use dynamic linking for packages, as it is much easier to fix a bug in a library once instead of in hundreds of depending packages. For software like OPM which the user compiles himself anyway (if not uses packages and thus packaged dependencies like UMFPACK are not a problem and the package maintainer is supposed to make sure that the software works correctly), it makes sense to default to static linking to avoid dependency issues and take advantage of the 1% performance improvement... We encountered a similar situation a while back on a seismic application where it turned out that statically linking of atlas and cblas was broken on Debian. Ref. https://github.com/CRAVA/crava/pull/22 Of course, CMake should test this for each library individually before using it... cheers Andreas -- A programmer had a problem. He thought to himself, I know, I'll solve it with threads!. has Now problems. two he -- Davidlohr Bue signature.asc Description: This is a digitally signed message part. ___ Opm mailing list Opm@opm-project.org http://www.opm-project.org/mailman/listinfo/opm
Re: [OPM] Umfpack runtime dependendy is problematic
On 2013-10-10 13:29, Bård Skaflestad wrote: despite the fact that I have a liblapack.a file (in /usr/lib), I got the diagnostic message below. This is on Ubuntu 10.04 LTS, CMake 2.8.0, and GCC 4.4.3. CMake Error at cmake/Modules/compat-2.8.7/FindLAPACK.cmake:295 A required library with LAPACK API not found. Please specify library location. This is because the code in /usr/lib/liblapack.a requires libm, but the probe in FindLAPACK.cmake is not smart enough to add this library to the link. (If you link to the shared library, the dynamic linker adds libm from the NEEDED record in the ELF header). So; the Looking for cheev_ test fails not because it is missing cheev_ (in liblapack), but because it is missing sqrtf (in libm). To add insult to injury, there doesn't seem to be any backdoor to sneak it in either; it calls FindBLAS which reset (!) BLAS_LIBRARIES even though it is already found (sic). To make matters even worse, the static LAPACK libraries seems to be broken from upstream (for which there is a proposed fix from a certain Markus Blatt :-)), which has made a good excuse for Kitware not to fix *this* bug. -- Roland. ___ Opm mailing list Opm@opm-project.org http://www.opm-project.org/mailman/listinfo/opm
