[Rivet] DISLepton Class fails to find outgoing lepton

[Marian Heil]

Hi Andrii,

Its a simple SM e p > e 3j process. I attached the HepMC file again. You 
are right with Sherpa using some "big" vertices, but for me the result 
doesn't looks like a Sherpa bug.

Cheers,
Marian


On 14/11/17 16:43, Andy Buckley wrote:
> Hi Andrii,
>
> If the particle status codes are not 1 or 2, there is no guarantee
> that HepMC vertices correspond to physical processes. They may just be
> bookkeeping devices, e.g. to absorb parton shower recoils (or in this
> case perhaps the QED radiation treatment) -- this wouldn't be a Sherpa
> bug, but a valid use of the freedoms in the HepMC standard. So we
> can't have projection code that assumes particular vertex structures,
> because there will always be such edge-cases.
>
> Can you explain what the logic of your DIS lepton finder is? (The code
> is not super-easy to follow.) Hopefully an understanding of the
> intention will help us to find a safer definition.
>
> Thanks,
> Andy
>
>
> On 14 November 2017 at 16:32, Andrii Verbytskyi
> <andrii.verbytskyi at desy.de> wrote:
>> Hi Marian, Andy,
>>
>> 0) I see no attachment. It is hard to guess which kind of process will
>> produce electron+ some leptons from a single electron.
>> If that is not SM process, the code was not designed to handle BSM.
>> 1) Yes, it is complicated with Sherpa. It merges too many things
>> together in one vertex. Just skip events with no electron/bad electron.
>> 2) Everything "works" in "some way" with some conditions.
>> 3) I cannot say without looking at the event that this is Sherpa
>> problem, but I suspect it is, so it is not clear if any fix is needed.
>>
>>
>> Best regards,
>> Andrii
>>
>>
>> On Tue, 2017-11-14 at 15:06 +0000, Andy Buckley wrote:
>>> Hi Marian,
>>>
>>> Thanks for the report. I've CC'd Andrii, who provided that updated
>>> DISLepton logic. Andrii, can you comment on how we can fix this
>>> behaviour in a generator-independent way?
>>>
>>> Andy
>>>
>>>
>>> On 10 November 2017 at 16:32, Marian Heil <marian.heil at durham.ac.uk> wrote:
>>>> Dear rivet authors,
>>>>
>>>> I think I found a bug in the DISLepton class in rivet version 2.5.4: It does
>>>> not find the outgoing lepton for a DIS scattering generated with Sherpa (the
>>>> corresponding HepMC file is attached).
>>>>
>>>> As far as I understand it in DISLepton::project the iteration over all
>>>> vertices and fails on the vertex "-6", because there are two outgoing
>>>> leptons ("10009" and "10015"). The first electron loops over vertex "-5"
>>>> back into vertex "-6" (for what ever reason), so it is not an actual final
>>>> state particle. The old code from version 2.5.3 does actually work for the
>>>> event.
>>>>
>>>> Cheers,
>>>> Marian
>>>>
>>>>
>>>> _______________________________________________
>>>> Rivet mailing list
>>>> Rivet at projects.hepforge.org
>>>> https://www.hepforge.org/lists/listinfo/rivet
>>>
>>>
>>
>
>

-------------- next part --------------

HepMC::Version 2.06.09
HepMC::IO_GenEvent-START_EVENT_LISTING
E 0 -1 -1.000000000000e+00 5.944769719026e-01 7.763841138914e-03 0 -5 6 10001 10003 0 5 2.708341235749e+04 2.684937688299e-02 6.152626385902e+05 1.000000000000e+00 0
N 5 "0" "1" "2" "3" "4" 
U GEV MM
C 2.708341235749e+04 2.708341235749e+04
F 11 21 9.999999999990e-01 2.813216091965e-02 1.829247728982e+01 1.000000000000e+00 3.734367368801e+00 0 0
V -1 0 0 0 0 0 1 1 1 1.000000000000e+00
P 10001 11 0 0 2.750000000000e+01 2.750000000000e+01 0 4 0 0 -1 0
P 10002 11 0 0 2.750000000000e+01 2.750000000000e+01 0 11 0 0 -4 0
V -2 0 0 0 0 0 1 1 1 1.000000000000e+00
P 10003 2212 0 0 -8.199994631984e+02 8.200000000000e+02 9.382719999513e-01 4 0 0 -2 0
P 10004 2212 0 0 -8.199994631984e+02 8.200000000000e+02 9.382719999513e-01 11 0 0 -3 0
V -3 0 0 0 0 0 0 3 1 1.000000000000e+00
P 10005 21 0 0 -2.306836440342e+01 2.306836440342e+01 7.539457464620e-07 11 0 0 -6 2 1 607 2 606
P 10006 2203 0 0 -6.441701750908e+02 6.441701750908e+02 0 1 0 0 0 1 2 607
P 10007 1 0 0 -1.527614605058e+02 1.527614605058e+02 0 1 0 0 0 1 1 606
V -4 0 0 0 0 0 0 1 1 1.000000000000e+00
P 10008 11 0 0 2.750000000000e+01 2.750000000000e+01 -5.840038639982e-07 11 0 0 -6 0
V -5 1 0 0 0 0 0 4 1 1.000000000000e+00
P 10011 11 -5.607636075307e+00 7.747853508143e+00 4.475820655829e+00 1.055972475398e+01 1.192092895508e-07 3 0 0 -6 0
P 10012 21 2.264370864740e+00 -3.480054666808e+00 -8.091330681286e+00 9.094382227012e+00 2.665600749850e-07 3 0 0 -6 0
P 10013 4 -9.660569608704e-02 6.765375841048e-01 -1.095707725905e+01 1.097836863218e+01 -3.153981341201e-07 3 0 0 -6 0
P 10014 -4 3.439870906654e+00 -4.944336425440e+00 1.900422288110e+01 1.993588879024e+01 2.384185791016e-07 3 0 0 -6 0
V -6 4 0 0 0 0 0 6 1 1.000000000000e+00
P 10009 11 0 0 2.750000000000e+01 2.750000000000e+01 -5.840038639982e-07 3 0 0 -5 0
P 10010 21 0 0 -2.306836440342e+01 2.306836440342e+01 3.371747880872e-07 3 0 0 -5 0
P 10015 11 -5.607636075307e+00 7.747853508143e+00 4.475820655829e+00 1.055972475398e+01 1.192092895508e-07 1 0 0 0 0
P 10016 21 2.264370864740e+00 -3.480054666808e+00 -8.091330681286e+00 9.094382227011e+00 2.064765462361e-07 1 0 0 0 2 1 602 2 606
P 10017 4 -9.660569608702e-02 6.765375841047e-01 -1.095707725905e+01 1.097836863218e+01 3.769728732310e-07 1 0 0 0 1 1 607
P 10018 -4 3.439870906654e+00 -4.944336425440e+00 1.900422288110e+01 1.993588879024e+01 0 1 0 0 0 1 2 602
HepMC::IO_GenEvent-END_EVENT_LISTING