I have built various libraries that are helpful for running IMP on the cluster and put them in my home directly there (~drussel/production). The libraries available are - ~drussel/production/hdf5: the version of hdf5 installed on the cluster is old and has several important differences from more recent versions. Backporting the hdf5 code looks to be a bit painful and messy and hdf5 is very easy to build. - ~drussel/production/bullet: the physics based optimizer, it is not installed in the cluster - ~drussel/production/CGAL: the geometry library, it is not installed in the cluster
If you want to use any of those, I suggest you copy them to your own directory somewhere and then add that directory to you imp config paths (libpath, includepath and ldlibpath). That way you won't have problems if I mess with my copies. None of the libraries have data and so they all work fine when relocated.
Ultimately, the nicest solution might be to have IMP include them or fetch them when needed itself. But I don't feel like setting that up now.
On 04/25/2011 02:31 PM, Daniel Russel wrote: > - ~drussel/production/hdf5: the version of hdf5 installed on the > cluster is old and has several important differences from more recent > versions. Backporting the hdf5 code looks to be a bit painful and > messy and hdf5 is very easy to build.
Yes, it's trivial to upgrade the version installed on the cluster. You could have simply asked. ;) I will do so.
> - ~drussel/production/bullet: the physics based optimizer, it is not > installed in the cluster - ~drussel/production/CGAL: the geometry > library, it is not installed in the cluster
Both bullet and CGAL are indeed installed on the interactive nodes. You simply need to copy the shared libraries to a suitable shared location if you want to run bullet- or CGAL-enabled IMP on the cluster. For example, the nightly builds already do so: see /salilab/diva1/home/imp/nightly/lib/x86_64-intel8/ for 64-bit DSOs.
Ben
On 04/25/2011 02:36 PM, Ben Webb wrote: > Yes, it's trivial to upgrade the version [of HDF5] installed on the cluster. You > could have simply asked. ;) I will do so.
In fact, it's so trivial that I had already done it. The interactive nodes already have hdf5-1.8.5.patch1 installed, which is a very recent version (I see they just released 1.8.6, but there are few changes between the two).
Ben
On Apr 25, 2011, at 2:36 PM, Ben Webb wrote:
> On 04/25/2011 02:31 PM, Daniel Russel wrote: >> - ~drussel/production/hdf5: the version of hdf5 installed on the >> cluster is old and has several important differences from more recent >> versions. Backporting the hdf5 code looks to be a bit painful and >> messy and hdf5 is very easy to build. > > Yes, it's trivial to upgrade the version installed on the cluster. You > could have simply asked. ;) I will do so. Yeah, but it was pretty trivial to build oneself and I assumed that the cluster was as up to date as was easy :-) Anyway, upgrading it is, of course, better.
> >> - ~drussel/production/bullet: the physics based optimizer, it is not >> installed in the cluster - ~drussel/production/CGAL: the geometry >> library, it is not installed in the cluster > > Both bullet and CGAL are indeed installed on the interactive nodes. You > simply need to copy the shared libraries to a suitable shared location > if you want to run bullet- or CGAL-enabled IMP on the cluster. For > example, the nightly builds already do so: see > /salilab/diva1/home/imp/nightly/lib/x86_64-intel8/ for 64-bit DSOs. They are not installed on the optint nodes, for example.
On 4/25/11 2:51 PM, Daniel Russel wrote: > On Apr 25, 2011, at 2:36 PM, Ben Webb wrote: >> Both bullet and CGAL are indeed installed on the interactive nodes. > They are not installed on the optint nodes, for example.
The QB3 cluster interactive nodes are, of course, set up for the QB3 cluster as a whole. Josh, that cluster's sysadmin, prefers a small, infrequently changing package set (frequent upgrades make some people happy but many other people unhappy). We have our own interactive nodes, which I recommend for Sali lab people. They have a set of packages that is tailored to Sali lab needs, not QB3 as a whole.
Ben
> On 4/25/11 2:51 PM, Daniel Russel wrote: >> On Apr 25, 2011, at 2:36 PM, Ben Webb wrote: >>> Both bullet and CGAL are indeed installed on the interactive nodes. >> They are not installed on the optint nodes, for example. > > The QB3 cluster interactive nodes are, of course, set up for the QB3 > cluster as a whole. Josh, that cluster's sysadmin, prefers a small, > infrequently changing package set (frequent upgrades make some people > happy but many other people unhappy). We have our own interactive nodes, > which I recommend for Sali lab people. They have a set of packages that > is tailored to Sali lab needs, not QB3 as a whole. I assumed that the QB3 cluster's interactive nodes tracks the packages installed on the compute nodes. Since IMP needs these various libraries at runtime, then I don't see how having them installed on the salilab interactive nodes helps. So I'm still confused :-)
On 4/25/11 6:57 PM, Daniel Russel wrote: > I assumed that the QB3 cluster's interactive nodes tracks the > packages installed on the compute nodes.
Nope. The interactive nodes contain extra packages that are not present on the compute nodes.
> Since IMP needs these > various libraries at runtime, then I don't see how having them > installed on the salilab interactive nodes helps. So I'm still > confused :-)
As I said in my earlier mail, simply copy whichever libraries you need from the machine you build IMP on to a suitable location. The easiest place would be the same directory you install the IMP libraries in.
Ben
>> Since IMP needs these >> various libraries at runtime, then I don't see how having them >> installed on the salilab interactive nodes helps. So I'm still >> confused :-) > > As I said in my earlier mail, simply copy whichever libraries you need > from the machine you build IMP on to a suitable location. The easiest > place would be the same directory you install the IMP libraries in. Sure, one can do that. But building the libraries from scratch is less effort and less consuming of my time (as opposed to CPU time). And having them bundled together in a place one can get with one cp command is even easier.
participants (2)
-
Ben Webb -
Daniel Russel