[Rivet] Rivet with POWHEG-BOX

[Andy Buckley]

Hi Tomas,

Hmm, very strange. No, there's no HepMC standard on barcodes -- 
actually, it's been removed from HepMC3, replaced by an immutable ID 
code and several ways of storing extra identity/origin information. And 
Rivet doesn't use it for anything other than checking particle equality: 
no interpretations based on ranges of values. (I just rechecked the 
code, to be certain.)

So I'm not sure why this would fix anything... but it did, so let's not 
complain ;-) Just keep an eye out for any other funny behaviours, in 
case this mysterious-but-convenient behaviour is actually hiding 
something problematic.

Cheers,
Andy


On 02/12/16 09:32, Tomas Jezo wrote:
> Dear Andy,
>
> Thank you for your reply. I compared my HepMC output with the output of
> Sherpa, for the same process, and realized that the key difference in
> the two are the particle barcodes. The HEPEVT conversion provided by
> HepMC seems to barcode particles starting from 1, while Sherpa starts
> from 10001. So if I re-barcode the particles in my events such that they
> start from 10001 Rivet works just fine. Does Rivet have any restrictions
> on particle barcodes? I couldn't find anything in the HepMC standard.
>
> Concerning the analysis, I didn't write it so I don't know the details,
> but I can attach it if you want to debug. I'd suspect this is analysis
> independent, but I haven't tried.
>
> For me, the renumbering solves the issue, but I'm happy to assist you
> should you consider this worthy a fix.
>
> Cheers,
> Tomas
>
> On 30/11/16 15:29, Andy Buckley wrote:
>> Actually, having started to make this addition, I realised that we do
>> have a GLUON identifier defined -- as for the quarks and many other
>> particles, but that only a few particles have string representations
>> -- basically only the ones that need to be translated from
>> command-line strings into beam-particle PIDs.
>>
>> This hasn't come up before because those PID -> string functions are
>> really for internal use. But maybe we accidentally propagated them
>> into the public interface. Can you let us know what you are doing that
>> results in them being called?
>>
>> In the long-term it'd be nice for us to find a neat way to define both
>> enums and strings for all PID codes, but that will take a bit more
>> work... and a good use-case.
>>
>> Cheers,
>> Andy
>>
>>
>> On 30/11/16 14:17, Andy Buckley wrote:
>>> Hi Tomas,
>>>
>>> Sorry for the delayed reply, I missed this at the time.
>>>
>>> I suspect the reason that it only fails on the second event is that we
>>> use the first event to establish beam particles and energies, so the
>>> second event is the first one on which an analyze() step failure is
>>> possible. I'm not 100% certain about that, though.
>>>
>>> As for the reason for the failure, I don't know what your analysis
>>> routine is doing, but it's failing when trying to write out a string
>>> representation of the particle name. Are you trying to do such a
>>> printout? You should be able to catch the error, but it'd be reasonable
>>> for us not to throw such a major error for a (probably) cosmetic
>>> failure. I will now add the gluon to the list of named particles -- it's
>>> not currently in there because of Rivet's focus on more physically sound
>>> post-hadronisation particles, but we already support quark names so it
>>> makes sense to also know about gluons. I can't guarantee that all
>>> analyses will work well with parton-level final-states, though -- take
>>> care!
>>>
>>> Andy
>>>
>>>
>>> On 14/11/16 14:59, Tomas Jezo wrote:
>>>> Dear Rivet authors,
>>>>
>>>> I'm trying to analyze events generated by POWHEG-BOX using Rivet (rivet
>>>> v2.4.3). I'm using the `HepMC::IO_HEPEVT` to convert the events from
>>>> the
>>>> HEPEVT format and them pass them to rivet:
>>>>
>>>> HepMC::GenEvent* evt = hepevtio.read_next_event();
>>>> rivet.analyze(*evt);
>>>>
>>>> Unfortunately i get the following error:
>>>>
>>>> terminate called after throwing an instance of 'Rivet::PidError'
>>>>   what():  Particle ID '21' not known.
>>>>
>>>> starting from event 2 (event 1 succeeds).
>>>>
>>>> If I write events into a file I get:
>>>>
>>>> HepMC::Version 2.06.09
>>>> HepMC::IO_GenEvent-START_EVENT_LISTING
>>>> E 1 -1 -1.0000000000000000e+00 -1.0000000000000000e+00
>>>> -1.0000000000000000e+00 0 0 1 1 2 0 1 1.1406100000000000e+01
>>>> N 1 "0"
>>>> U GEV MM
>>>> V -1 0 0 0 0 0 2 4 0
>>>> P 1 21 0 0 3.4591526030000000e+02 3.4591526030000000e+02 0 -1 0 0 -1 0
>>>> P 2 21 0 0 -4.2588502149999999e+02 4.2588502149999999e+02 0 -1 0 0 -1 0
>>>> P 3 6 -1.4833769729999999e+00 -1.2369079390000000e+02
>>>> 2.3239638199999999e+02 3.1474742459999999e+02 1.7250000000000000e+02
>>>> 1 0
>>>> 0 0 0
>>>> P 4 -6 -1.2441412769999999e+01 9.4068674470000005e+01
>>>> -3.5206476490000000e+02 4.0337272209999998e+02 1.7250000000000000e+02 1
>>>> 0 0 0 0
>>>> P 5 5 7.2436624820000004e+00 2.2627455149999999e+01
>>>> 3.3183952779999998e+01 4.1087827820000001e+01 4.7500000000000000e+00
>>>> 1 0
>>>> 0 0 0
>>>> P 6 -5 6.6811272600000002e+00 6.9946643320000002e+00
>>>> 6.5146689540000002e+00 1.2592307260000000e+01 4.7500000000000000e+00
>>>> 1 0
>>>> 0 0 0
>>>> E 2 -1 -1.0000000000000000e+00 -1.0000000000000000e+00
>>>> -1.0000000000000000e+00 0 0 1 1 2 0 1 1.1406100000000000e+01
>>>> N 1 "0"
>>>> U GEV MM
>>>> V -1 0 0 0 0 0 2 4 0
>>>> P 1 21 0 0 1.5871885349999999e+01 1.5871885349999999e+01
>>>> 6.7434957620000004e-07 -1 0 0 -1 0
>>>> P 2 21 0 0 -2.1900844820000002e+03 2.1900844820000002e+03 0 -1 0 0 -1 0
>>>> P 3 6 -1.3328056880000000e+01 -8.3731995950000009e+00
>>>> -7.8224201930000004e+02 8.0119072280000000e+02 1.7250000000000000e+02 1
>>>> 0 0 0 0
>>>> P 4 -6 2.1782820879999999e+01 1.1731505100000000e+01
>>>> -1.3307128740000001e+03 1.3420749320000000e+03 1.7250000000000000e+02 1
>>>> 0 0 0 0
>>>> P 5 5 -3.3212752330000002e+00 -2.3273609810000000e+00
>>>> -2.7406078330000000e+01 2.8108772790000000e+01 4.7500000000000000e+00 1
>>>> 0 0 0 0
>>>> P 6 -5 -5.1334887599999997e+00 -1.0309445209999999e+00
>>>> -3.3851624520000001e+01 3.4581939450000000e+01 4.7500000000000000e+00 1
>>>> 0 0 0 0
>>>> ....
>>>>
>>>> Same happens when I run rivet from the command line:
>>>> 1.) It succeeds when analyzing individual events (event 1 or event 2)
>>>> 2.) Fails if run with a file containing both
>>>>
>>>> What am I doing wrong? Would you have any advice for me?
>>>>
>>>> Many thanks.
>>>>
>>>> Cheers,
>>>> Tomas
>>>>
>>>> _______________________________________________
>>>> Rivet mailing list
>>>> Rivet at projects.hepforge.org
>>>> https://www.hepforge.org/lists/listinfo/rivet
>>>
>>>
>>
>>
>


-- 
Dr Andy Buckley, Lecturer / Royal Society University Research Fellow
Particle Physics Expt Group, University of Glasgow