[Rivet] Fwd: Running RAPGAP with RIVET

[Tim Martin]

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
>>
>>
>
>



-- 
-+-+-+-+ Tim Martin +-+ ATLAS +-+-+-+-
Physics West, Room W313
University of Birmingham, B152TT
Tel: (+44)121 414 4631
Web: http://cern.ch/Tim.Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: agile_out
Type: application/octet-stream
Size: 8878 bytes
Desc: not available
Url : http://www.hepforge.org/lists-archive/rivet/attachments/20100416/56719fe9/attachment.obj