[Rivet] MC_HJETS and MC_HINC using ZFinder

[Andy Buckley]

Hi all,

Sorry to have taken such a long time to come back to this issue. In the
Rivet trunk I have fixed the MC_HJETS/HINC/HKTSPLITTINGS analyses to
(ab)use the ZFinder with a mass range of 115-135 GeV and a mass target
of 125 GeV (to summarise earlier messages, it was previously 115-125 GeV
and a mass target of mZ). The ZFinder constructor is now:

ZFinder hfinder(FinalState(), cut, PID::TAU, 115*GeV, 135*GeV, 0.0,
ZFinder::NOCLUSTER, ZFinder::NOTRACK, 125*GeV);

I agree with the idea that we should use distinct types for this --
using the ZFinder here was always a hack. In fact we do already have a
ParticleFinder base class, with a plan for migration of various "finder"
projections to inherit from this rather than FinalState. The latter has
led to various misleading names, most notably the oxymoronic
UnstableFinalState ;-) Since this is largely just a matter of
nomenclature and semantics, it's not been a priority up to now, but I
think the time has come to sort this out -- and maybe to add a
HiggsFinder at the same time.

I have left the default ZFinder target mass at mZ because, er, it's a
ZFinder and the Z mass is well-defined. If we were to push some of this
logic "upstairs" into a ParticleFinder subclass like
(Dilepton)ResonanceFinder then it would make complete sense for that
generic resonance finder to return all dilepton pairs, i.e. without a
mass target to identify the "best" pair. The way we do it depends on how
much code duplication we can really avoid by adding more inheritance layers.


SLIGHTLY OFF-TOPIC:

I feel a bit awkward about the "HiggsFinder" suggestion since, unlike
for W & Z where the main experimentally used decay modes are directly
leptonic, the direct di-leptonic Higgs decay modes are not what most
people are interested in looking for. But sure, we could fix the mass
target and PID problems with a minimal
"LeptonicHiggsFinder"/"HiggsFinderDilepton"/"HiggsFinderLL", paving the
way to also add HiggsFinderDiphoton, HiggsFinderLeptonicWW, etc. The
problem with those is that as final states become more complex,
especially when jets are involved and double-especially when jet
substructure methods are used, there ceases to be one obvious way to do
it... and if every analysis has a different procedure for resolving
ambiguities, doing mass-constrained fits, etc. then there's no benefit
to doing the finding in a projection: it might as well be coded up
differently in each analysis class. That's why we don't (yet) have a
TopFinder, nor a HadronicWFinder.

Cheers,
Andy


On 26/03/15 12:29, Hunt, Julia wrote:
> Hello all,
> 
> maybe just a suggestion from the outside:
> 
> How about creating a general ParticleFinder class and derive two child classes (HiggsFinder and ZFinder)? Or even a third one to return all possible combinations?
> 
> By the way, there is an additional flaw in using the current ZFinder for finding a Higgs jet.
> The particle ID of the found bosons is set to the Z ID, see line 131
> 
> _bosons.push_back(Particle(PID::ZBOSON, pZ));
> 
> Derived classes could be used to solve this.
> 
> Best regards,
> 
> Julia and Marco
> ________________________________________
> Von: Frank Siegert [frank.siegert at cern.ch]
> Gesendet: Donnerstag, 26. März 2015 12:54
> An: Andy Buckley
> Cc: Chris Pollard; rivet at projects.hepforge.org; Hunt, Julia
> Betreff: Re: [Rivet] MC_HJETS and MC_HINC using ZFinder
> 
>>> I think Julia has a point, namely that additionally to the mass range
>>> we can specify a mass target, which means that only the pair closest
>>> to the target is being kept. At least in the Higgs analyses this
>>> should be changed:
>>> - to 0 such that all possible pairs are kept for the user to decide, or
>>> - to 125 such that the correct pair is kept
>>>
>>> Maybe we want to change this to 0 in general? I just don't know
>>> whether there are any analyses that rely on it being 91 at the moment,
>>> but we could simply set it explicitly to 91 in all existing analyses
>>> using the ZFinder such as to remain backward compatible.
>>
>> This would be a possibility, but it *is* a ZFinder. If we think that
>> selecting the Z candidate closest to the known Z mass is reasonable in
>> all the existing analyses using ZFinder then I think we should keep it
>> there.
>>
>> Seems to me that the main point is to change the range to one centred on
>> 125*GeV in these MC_H* analyses, and to also explicitly set the mass
>> target either to 125 or to 0 in them. This use of ZFinder is the
>> exception, rather than a reason to change the default, IMHO.
> 
> One could also argue that a good default for the ZFinder is to return
> all allowed combinations within the given mass range. So the user
> would then decide how to pick one and discard the other, or (more
> likely) completely discard the rare events where there are two Z's. I
> would think that the latter is something more commonly (and easily)
> implemented in experimental analyses?
> 
> Cheers,
> Frank
> 


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