[Rivet] Treament of Z/W Bosons in Rivet

[Andy Buckley]

Hi Chris,

Absolutely, we should validate and investigate the effect. We did 
exactly the same thing when we switched the default from clustering all 
photons to clustering only prompt photons.

In that case, and I suspect in this one, there was barely any effect and 
in those which we checked the analysis had been written sloppily and the 
change was to a more correct fiducial definition. It'll require some 
checking, but I suspect that's also going to be the case for this 
change. You know the recent ATLAS EW analysis codes better than I do, 
though...

Andy


On 15/07/16 10:26, Christian Gutschow wrote:
> Hi all,
>
> hang on a second here. While I’m all in favour of adding something like
> PROMPT vs ALL enums to the W/ZFinder, I would be a little bit cautious
> about just changing past routines.
>
> There may be cases where adding the promptness requirement will have
> basically no effect and that’s fine, but there will be cases where it
> does have an effect and for those a change would invalidate the routine.
> Track-vertex association is something that’s usually done at the
> detector level, but that’s essentially irrelevant here. What matters is
> what the data have been unfolded to: If the particle-level definition
> includes non-prompt leptons and the data have been unfolded to that,
> then that’s what should go into the routine. Unfortunate, but still a
> valid particle-level definition.
>
> Cheers,
> Chris
>
>
>> On 14 Jul 2016, at 16:10, Andy Buckley <andy.buckley at cern.ch
>> <mailto:andy.buckley at cern.ch>> wrote:
>>
>> Hi David,
>>
>> Yes, that seems very sensible to me. And it needs to be an *internal*
>> application of the PromptFinalState because we have to respect the
>> flag for including non-prompt photons in the lepton dressing.
>>
>> Making it disableable is important, I think, but I'd be tempted to
>> change the default behaviour to only use prompt charged leptons.
>> Rather than use bools I think the interfaces should be extended to use
>> new W/ZFinder::ChargedLeptons { PROMPT, ALL } enums in the
>> constructors. To avoid clashes, maybe we should start using the more
>> powerful C++11 "enum class" syntax.
>>
>> Since this is an API & physics change, we probably need to target it
>> for Rivet 2.6.0. I would hence like to tie it in with the proposed API
>> changes to allow uniform access to composite particles, for the new
>> smearing system to use.
>>
>> Andy
>>
>>
>> On 14/07/16 15:55, Yallup, David wrote:
>>> Hi all,
>>>
>>>
>>> I've been looking at using the current library of Rivet analyses for BSM
>>> limit setting, which is going to be an exercise involving some 'safety
>>> proofing' of the analyses! One of the issues we've run into is spurious
>>> signals arising from fake Z/Ws that shouldn't be faking.
>>>
>>>
>>> For example a model adding additional heavy flavour pair production, the
>>> lepton pairs from heavy flavour hadron decays have the possibility to
>>> fake Z/W signals (has a noticeable statistical effect in cases). The way
>>> around is then to build the Z from promptfs projection, which has the
>>> right effect from our PoV (I have some modified versions of Z/W analyses
>>> of interest I've been running like this, written by David Grellscheid)
>>> and would be happy to propagate a change like this through through other
>>> analyses needed and hand them over for testing.
>>>
>>>
>>> I think this is a sensible safety feature to add, and is already
>>> something experiments have attempted to cater for in the definition of
>>> the fiducial cross section, via track-primary vertex association or
>>> something along those lines, so should be mirrored in the rivet routine.
>>> The question then is should there be a switch in the convenience
>>> Z/WFinders checking for isPrompt on the leptons by default? I think this
>>> would then be sensible for people going forward, as it would be sort of
>>> in the spirit of the Finders, doing the hard work for you and all that,
>>> and making the sensible choices needed by default. Obviously in quite a
>>> few cases the Finders aren’t even used, so sorting the projections out
>>> would still be done by hand.
>>>
>>>
>>> Anyway wanted to see if there are any opinions on this before I start
>>> churning through old analyses or anything like that.
>>>
>>>
>>> Cheers,
>>>
>>> David
>>>
>>>
>>>
>>> _______________________________________________
>>> Rivet mailing list
>>> Rivet at projects.hepforge.org <mailto: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
>> _______________________________________________
>> Rivet mailing list
>> Rivet at projects.hepforge.org <mailto:Rivet at projects.hepforge.org>
>> https://www.hepforge.org/lists/listinfo/rivet
>
>
>
>
>   —
>
>   Dr. Christian Gütschow
>
>   University College London
>   Department of Physics and Astronomy
>   Gower Street
>   London WC1E 6BT
>
>   > D10 Physics Building
>   > +44 (0)20 7679 3775
>   > chris.g at cern.ch <mailto:chris.g at cern.ch>
>
>
>
>


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