[Rivet] Rivet with POWHEG-BOX

[Tomas Jezo]

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