[Rivet] DISLepton Class fails to find outgoing lepton

[Andy Buckley]

Hi Andrii,

I'm not sure what you mean by your point 1)...?

On (2), I'm sure you're aware that the evoution of experimental
well-definedness has been gently evolving. There are also areas like
precision EW physics where definitions long held to be solid are being
challenged by theoretical advances. Also, HepMC and associated
standards are the operative definition of well-definedness: if those
standards are currently incompatible with a theoretically well-defined
process, then we should revisit the standards. "The lepton momentum
that interacts with a W/Z" is the sort of definition that has caused
problems, however, hence the ongoing shift towards more final-state
oriented fiducial definitions.

I had no idea that the distinction between this definition and the
former one was so strong... I thought we were talking about more like
a few percent. Obviously we need to find a balance.

Andy


On 14 November 2017 at 17:53, Andrii Verbytskyi
<andrii.verbytskyi at desy.de> wrote:
> Hi Andy,
>
> I had a long day, so in short:
> 1) works for me. With Sherpa as well.
> 2) DIS is well defined  since many years, in many experiments and MC
> programs. Regardless of Rivet, HepMC, you and me. Sad but true.
> 3) Last time "some accuracy" was 50% or so (I honestly do not remember).
> Not a good idea. For sure there will be a bunch of students that will
> not be aware (or will forget) that "some accuracy" is missing.
>
> Andrii
>
>
>
> On Tue, 2017-11-14 at 17:32 +0000, Andy Buckley wrote:
>> Unfortunately that DIS definition doesn't correspond to something
>> well-defined in HepMC. There is no standard for hard-process
>> interaction representation.
>>
>> It would be good to know if this works with the Sherpa tree-like mode,
>> but generally we want to avoid such sensitivities. I am more inclined
>> to sacrifice some accuracy
>
>
>> for robustness... and an observable
>> definition that cannot be reproduced is a fundamentally problematic
>> thing.
>
>
>
>
>
>> Andy
>>
>>
>> On 14 November 2017 at 17:05, Andrii Verbytskyi
>> <andrii.verbytskyi at desy.de> wrote:
>> > Hi Marian, Andy,
>> >
>> > 0) The event contains loops. It is better to generate events with Sherpa
>> > with HEPMC_TREE_LIKE=1 or so. See docs.  Have you used it?
>> >
>> >
>> > 1)
>> > On Tue, 2017-11-14 at 16:43 +0000, 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.
>> >
>> > In general you are right, but not for electron in DIS that is coming
>> > from hard process. The only thing one expects from it is e->e+gamma  or
>> > e-> W nu ( not in Rivet anyway). But no hadronisation vertices.
>> >
>> >
>> > Sherpa mixes everything together, in one vertex.
>> > I haven't said that is a bug, but a *problem*. A problem for kinematics
>> > reconstruction.
>> >
>> >
>> >
>> >
>> >> 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.
>> >
>> > The logic comes from  DIS definition: scattered lepton is the beam
>> > electron that went through e->e gamma/Z0 or e-> W nu vertices.
>> >
>> >
>> > Best regards,
>> > Andrii
>> >
>> >> 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
>> >> >>
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >
>> >
>>
>>
>>
>
>



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