>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.
Then you do not understand corporate IT. EPEL is not supported by Red Hat. Hence you are basically asking why should anybody pay for Red Hat support. After all, we could just install Arch and take the support burden and risk ourselves. It is a problem, and it is not going away anytime soon. I am happy to explain this issue at length over a beer at any convenient occasion. >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. Sorry for my short answer to Joakim, but I did understand what he said. We will then need to install and maintain suitesparse out-of-tree on build nodes, today we use the standard dev packages. Installing extra rpms on build nodes is straight forward, we need a list of extra rpms there anyway where some are indeed from EPEL, so it really is a minimal burden. Hence build time dependencies is less of a problem than runtime dependencies. Yes, you are correct, we would not need LD_LIBRARY_PATH for suitesparse if we use RPATH, but as explained we would then need to do out-of-tree installs of suitesparse on build nodes and compute nodes. Throwing a couple of libs in the already set LD_LIBRARY_PATH is then a more attractive option. > 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 ;) In any case, I have just copied the two libs over to a folder which is available and set in LD_LIBRARY_PATH for all users of OPM. It will just be one more of those things that will break when we install Red Hat 6 and 7 on clusters. 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 [email protected] http://www.opm-project.org/mailman/listinfo/opm
