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
