[Rivet] DISLepton Class fails to find outgoing lepton

[Andrii Verbytskyi]

Hi David,

in principle yes, but not in the nearest future.
One can ask some students to do it.

Andrii

On Wed, 2017-11-15 at 11:44 +0000, David Grellscheid wrote:
> Andrii, can you please provide a test plot some time, showing the old
> and new behaviour of the projection before/after your fix in some
> exemplary analysis? I'm trying to assemble a set of interface stability
> tests (also for the XYZFinders), and this would be a good addition.
> 
> Thanks,
> 
>   David
> 
> 
> On 15/11/2017 11:38, David Grellscheid wrote:
> > Do I understand right that the answer to the "correct" lepton to pick
> > becomes analysis-specific, and a global projection is not suited for
> > everyone.
> > 
> > If the experimental analysis folds in some correction for the fact that
> > you may not have identified the "real" DIS lepton experimentally, then
> > going through the event tree in Rivet is (grudgingly ;-) ) acceptable.
> > 
> > If the analysis relies on a final-state definition of which lepton to
> > choose, then Rivet should use the same final-state definition, and would
> > not need to look at event trees.
> > 
> > See you,
> > 
> >   David
> > 
> > 
> > On 14/11/2017 18:32, Andrii Verbytskyi wrote:
> >> 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
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>
> >>
> >> _______________________________________________
> >> Rivet mailing list
> >> Rivet at projects.hepforge.org
> >> https://www.hepforge.org/lists/listinfo/rivet
> >>
> > _______________________________________________
> > Rivet mailing list
> > Rivet at projects.hepforge.org
> > https://www.hepforge.org/lists/listinfo/rivet
> >