|
[Rivet] DISLepton Class fails to find outgoing leptonAndrii Verbytskyi andriish at mpp.mpg.deTue 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 |