[Rivet] Fwd: Running RAPGAP with RIVET

[Sebastian White]

fantastic.
S
Sebastian White, Physics Deprtment	Brookhaven National Laboratory
Offiice: 631-344-5488					cell: 516-443-0039
email: swhite at bnl.gov				Sebastian.White at cern.ch



On Apr 16, 2010, at 11:49 AM, Tim Martin wrote:

> Sucess!
> 
> That last step did it, I now have hepmc_rapGap.fifo.
> 
> To summarise for myself and for anyone else who wants to try this in the future:
> 
> *Got RapGap pre-compiled from Hannes Jung
> cp -r ~jung/public/rapgap/ ~/scratch0/
> 
> *Made the shared library
> cd ~/scratch0/rapgap/Lib
> mkdir temp
> cd temp
> ar -x ../librapgap32.a
> gcc -shared *.o ../../rapgap-3.202-beta-0.1/bases51/*.o
> ../../rapgap-3.202-beta-0.1/misc/*.o -o ../librapgap32.so
> 
> *Installed RIVET and BOOST (was not liking CERN's boost install for
> some reason) from the bootstrap provided on the RIVET web page
> cd /tmp
> wget http://svn.hepforge.org/rivet/bootstrap/rivet-bootstrap
> chmod +x rivet-bootstrap
> ./rivet-bootstrap --prefix=$HOME/scratch0/local --install-boost
> 
> *Got the head of AGILe from SVN
> svn co http://svn.hepforge.org/agile/trunk
> *Reverted src/Core/Loader.cc to r700
> *Added 'baselibs.push_back(GenLibInfo("libpythia6_dummy", "pythia6",
> "421"));' after line 361
> *Set rapgap path
> export AGILE_GEN_PATH=$HOME/scratch0/rapgap
> *Configured & installed AGILe with
> autoreconf -i --force
> chmod +x configure
> ./configure --prefix=$HOME/scratch0/local
> --with-lcgtag=slc4_amd64_gcc34
> --with-hepmc=/afs/cern.ch/sw/lcg/external/HepMC/2.05.00/slc4_amd64_gcc34
> --with-boost=$HOME/scratch0/local --enable-pyext
> make -j2 && make -j2 install
> 
> *Ran with
> agile-runmc Rapgap:32 -n 100000 -o hepmc_rapGap.fifo <
> ~tam/scratch0/rapgap/share/steer-pp-rapidity-gap
> 
> Once again, many thanks for all your help getting me to this point,
> now to look at the distributions :)
> Cheers,
> Tim.
> 
> On 16 April 2010 16:01, Holger Schulz <holger.schulz at physik.hu-berlin.de> wrote:
>> Hi Tim,
>> 
>> I think you need to link also to the objects in the folder
>> misc and bases51 (vzero is in misc) when you create
>> librapgap32.so.
>> Can you give it a try?
>> 
>> Holger
>> 
>> 
>> Tim Martin wrote:
>>> 
>>> Thanks Andy, Holger.
>>> 
>>> 
>>>>> 
>>>>> it's _dummy, not _dummies. And the test done to put the generator in the
>>>>> 
>>> 
>>> A little progress, I changed the line I inserted into the old Loder.cc to
>>> 
>>> baselibs.push_back(GenLibInfo("libpythia6_dummy", "pythia6", "421"));
>>> 
>>> And we get further! Pythia now initialises, but then
>>> 
>>> AGILe.Rapgap: INFO  Calling PTIME...
>>> python: symbol lookup error:
>>> /afs/cern.ch/user/t/tamartin/scratch0/rapgap/lib/librapgap32.so:
>>> undefined symbol: vzero_
>>> 
>>> Full log att.
>>> Tim.
>>> 
>>> On 16 April 2010 15:17, Holger Schulz <holger.schulz at physik.hu-berlin.de>
>>> wrote:
>>> 
>>>> 
>>>> Andy Buckley wrote:
>>>> 
>>>>> 
>>>>> On 16/04/10 12:01, Tim Martin wrote:
>>>>> 
>>>>> 
>>>>>> 
>>>>>> Hi Andy,
>>>>>> 
>>>>>> I tried the new Loder.cc reautoconf'd, configured and made. AGILe did
>>>>>> not then find RAPGAP as an option to run.
>>>>>> 
>>>>>> Interestingly, I reverted back to r700, re-installed, got the old
>>>>>> error back then added the one line below
>>>>>> 
>>>>>> baselibs.push_back(GenLibInfo("libpythia6", "pythia6", "421"));
>>>>>> //L361
>>>>>> baselibs.push_back(GenLibInfo("libpythia6_dummies", "pythia6",
>>>>>> "421"));  //L362 - Tim addition
>>>>>> 
>>>>>> Once more, after compilation, rapgap was not found.
>>>>>> 
>>>>>> 
>>>>> 
>>>>> I probably arsed up how the rapgap library finding is done. In
>>>>> particular, I think my rewrite hack would have been looking for
>>>>> .../32/.../librapgap.so rather than librapgap32.so. I'm in a training
>>>>> course all day with virtually no internet access (this is a 15 min
>>>>> coffee break!)... Holger, can you try my hacked version and make it work
>>>>> for you again?
>>>>> 
>>>>> 
>>>> 
>>>> Ok I will try and tell you when it's done. I will be stuck in a meeting
>>>> and won't be able to work on that until 6pm CERN time.
>>>> 
>>>> Holger
>>>> 
>>>>> 
>>>>> Then Tim can try adding the libpythia6_dummy finding line again. Note:
>>>>> it's _dummy, not _dummies. And the test done to put the generator in the
>>>>> list is just checking to see if those libraries can be *found*, not that
>>>>> they successfully load and cover all symbol requirements: we used to do
>>>>> the latter, but it introduced a very subtle problem! So that you're not
>>>>> getting a RapGap variant in the list with my hack implies that my hack
>>>>> is not looking for the right path to the Rapgap library... Holger can (I
>>>>> hope) fix that. That adding the _dummies line to r700 makes Rapgap
>>>>> disappear from the gens list is because the library isn't called
>>>>> *_dummies!
>>>>> 
>>>>> 
>>>>> 
>>>>>> 
>>>>>> I'm getting...
>>>>>> 
>>>>>> nm -CD libpythia6.so | grep pytime
>>>>>> U pytime_
>>>>>> 
>>>>>> nm -CD libpythia6_dummy.so | grep pytime
>>>>>> 00000000000016a0 T pytime_
>>>>>> 
>>>>>> nm librapgap32.so | grep pytime
>>>>>> *nothing*
>>>>>> 
>>>>>> 
>>>>> 
>>>>> Okay, so Rapgap doesn't contain this dummy function. I think
>>>>> libpythia_dummy needs to be loaded as well: Holger didn't notice this
>>>>> because he has a version of the Pythia library which already contains
>>>>> all the dummy functions, but the Genser libs do not.
>>>>> 
>>>>> 
>>>>> 
>>>>>> 
>>>>>> As for running rapgap without AGILe, it produces a few event summaries
>>>>>> (I presume it will output all with changes to steering) along with all
>>>>>> the other assorted MC output (~tamartin/public/rapgapout), I tried
>>>>>> piping it straight into rivet and manually snipping out the event
>>>>>> summaries bit and running over the file but both times just says:
>>>>>> 
>>>>>> streaming input: end of stream found setting badbit.
>>>>>> Failed to initialise on event file -
>>>>>> 
>>>>>> 
>>>>> 
>>>>> Yeah, it's not writing HepMC -- that's why it can't be read in. You
>>>>> could hack Rapgap itself to write out HepMC, but that would involve
>>>>> getting familiar with Fortran/C++ intercommunication, which is exactly
>>>>> the convenience problem that AGILe is meant to solve. So let's
>>>>> persevere: I think it shouldn't take much longer!
>>>>> 
>>>>> Andy
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> ------------------------------------------------------------------------
>>> 
>>> _______________________________________________
>>> Rivet mailing list
>>> Rivet at projects.hepforge.org
>>> http://www.hepforge.org/lists/listinfo/rivet
>> 
>> 
> 
> 
> 
> -- 
> -+-+-+-+ Tim Martin +-+ ATLAS +-+-+-+-
> Physics West, Room W313
> University of Birmingham, B152TT
> Tel: (+44)121 414 4631
> Web: http://cern.ch/Tim.Martin