[Rivet] Fwd: Running RAPGAP with RIVET

Andy Buckley andy.buckley at ed.ac.uk
Thu Apr 15 23:21:30 BST 2010


On 15/04/10 15:11, Tim Martin wrote:
> I guess so, I've tried other versions of Pythia through changing the...
> 
> baselibs.push_back(GenLibInfo("libpythia6", "pythia6", "419"));
> 
> ...line but no luck.

I've just rewritten some chunks of that code to make AGILe (the SVN
head) try all versions of Pythia. It shouldn't change the symbol content
of the libraries though: that bit doesn't change between versions. In
particular, PYTIME is a dummy routine because different FORTRAN
implementations provide different extensions for getting date-time
information.

Okay, here's some examples of where pytime_ is defined: it's undefined
in Genser's libpythia.so, which is why you need it:

andy at duality:~/proj/hep/agile$ nm
/home/andy/genserarea/pythia6/422.2/i686-Linux-gcc44-opt/lib/libpythia6.so
| grep pytime
         U pytime_

(U="undefined")

but it is defined in libpythia_dummy.so, which is why AGILe works for
the normal Pythia, which loads the dummies library:

andy at duality:~/proj/hep/agile$ nm
/home/andy/genserarea/pythia6/422.2/i686-Linux-gcc44-opt/lib/libpythia6_dummy.so
| grep pytime
00000e70 T pytime_

(T="text")

I'm assuming that Charybdis, AlpGen and other generators that piggyback
on Pythia also supply their own pytime_ dummy, since none of the AGILe
libraries currently provide (or even know about) it:

andy at duality:~/proj/hep/agile$ for i in
/home/andy/heplocal/lib/libAGILe*.so; do nm $i | grep pytime; done
andy at duality:~/proj/hep/agile$

Can you try running
nm path/to/librapgap.so | grep pytime
to see if it defines this symbol? Maybe we should be loading
libpythia_dummies as well... I've added it in commented-out form on line
368 of the src/Core/Loader.cc file (in the SVN head), so you could try
updating from SVN, uncommenting, recompiling and reinstalling and see if
it helps. Maybe get a different error message, at least ;)

 Also tried your suggestion of piping rapgap
> straight into Rivet but that sadly did not work either.

Weird. My only guess is that it isn't writing HepMC... maybe its own
format, maybe a dump of the HEPEVT common block?

Andy

-- 
Dr Andy Buckley
SUPA Advanced Research Fellow
Particle Physics Experiment Group, University of Edinburgh


More information about the Rivet mailing list