[Rivet] Running Rivet on the grid

[Frank Siegert]

I have a few suggestions for the grid run strategy, which mainly appeared 
when I started building the validator:

We should adapt the downloaded grid-tarballs more to which generator is 
being run. Is Genser available on the grid nodes? I assume no, because 
you are including the "fake" Genser tree in your package, which then I 
think should be split up.
Right now it would download ~80 MB and that even only includes charybdis, 
herwig, jimmy and pythia. For some generators we don't even need 
AGILe/Genser, but use them through a socket.

Do you think it is feasible to link AGILe at runtime (if found in 
LD_LIBRARY_PATH) instead of compile time? Since we have identified all 
relevant places with an "#ifdef HAVE_AGILE" already, this might not be so 
hard? Of course, during compilation one would need the AGILe headers 
anyways. If nobody has a better suggestion, I could look into this. 
Another option would be providing two Rivet tarballs, one compiled with 
AGILe, and one without.

And as far as I know there is already a mechanism in AGILe which checks 
and enables only the generator interfaces it can find in LD_LIBRARY_PATH, 
right?

Then we can split up the downloaded packages into
 - HepMC*
 - LHAPDF*
 - FastJet*
 - (boost is not needed, because we only use header files AFAIK)
 - Rivet
   + libgsl.so link (from what i have noticed, this is missing on SL4,
     but might only be needed during compilation?)
 - AGILe core
 - Each generator*, including its AGILe library for the ones where we
   don't want to use the standalone generator through HepMC fifo.

* Everything marked with an asterisk is probably available on GENSER. So 
if we have Genser on grid nodes, it wouldn't be necessary to bundle them 
into our "grid tarball".

All of these should untar into the same temporary bin/ lib/ share/ 
directories on the grid node, so with a properly set PATH and 
LD_LIBRARY_PATH all programs can figure out what is available.

Does that sound reasonable?
Frank