[Rivet] DISLepton Class fails to find outgoing lepton

Andrii Verbytskyi andriish at mpp.mpg.de
Tue Nov 14 18:32:44 GMT 2017


Hi Andy,


1) the code for electron finding works for me fine.
Maybe because I use HEPMC_TREE_LIKE=1 for Sherpa. Maybe for other
reasons. That is just an observation. I suggest Marian will use it and
skip events with no lepton/broken lepton. Another option is to ignore
state=3 particles in the finder.

2) I'm sure there are cases where your arguments are valid, but 
as of 2017, (simple NC) DIS is well defined in PDG.
http://pdg.lbl.gov/2017/reviews/rpp2016-rev-qcd.pdf
Not the case you describe. Of course that might be different next year,
but I see no reasons for that and do not know anything about theoretical
advances that can change it. 

2a) Yes, final state definition is a good thing. That is why I find the
fact that Sherpa puts final state particles into hadronisation blob
problematic. But that is an implementation, not definition.

Best regards,
Andrii


On Tue, 2017-11-14 at 18:01 +0000, Andy Buckley wrote:
> 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
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >
> >> >
> >>
> >>
> >>
> >
> >
> 
> 
> 




More information about the Rivet mailing list