[Rivet] b-tagging in Rivet 2.x.x

[Andy Buckley]

Ah, I think HERWIG does not use the standard status=2 code for unstable
hadrons: it's one of the reasons to move away from using it. We had
implemented a status-rewriting feature in the ATLAS Herwig_i interface
to correct this, but I have a feeling that people were scared of change
and it never got switched on. I think it'll probably work for ~any other
generator, since HERWIG is the only one I know of that doesn't follow
the HepMC status scheme.

Andy


On 16/02/15 09:49, Christian Gütschow wrote:
> Hi Andy,
> 
> ooh, fancy that! I am liking this option best. :-)
> 
> Unfortunately, it doesn't seem to work for me either, i.e. both the
> bHadrons vector is empty and jet.bTagged() also returns false for all my
> selected jets (at least that's consistent), while the approach via the
> GenParticle container does find some b-jets.
> 
> I was using an Alpgen+Herwig sample for this test, namely a file from
> the mc11_7TeV.126733.AlpgenHerwigEvtGenWbb2p.evgen.EVNT.e1155 container.
> 
> Cheers,
> Chris
> 
> 
> On 15 February 2015 at 23:10, Andy Buckley <andy.buckley at cern.ch
> <mailto:andy.buckley at cern.ch>> wrote:
> 
>     Hi Christian,
> 
>     The best way to do it now is if (jet.bTagged()) ;-)  This uses ghost
>     association to hadrons.
> 
>     The HeavyHadrons way should work, though, so I'm very puzzled that it
>     doesn't. What generator are you using? Is the bHadrons vector non-empty?
>     Could you try printing the dRs in that comparison? (By the way, you
>     shouldn't need to re-apply the > 5 GeV cut in the loop, since that's one
>     of your b-hadron selection criteria!)
> 
>     Andy
> 
>     PS. I will get back to you about the merging issue. I didn't get any
>     chance in the last 2 weeks, but have a "free" week coming up so will do
>     my best. Prod me if I don't!
> 
> 
>     On 15/02/15 14:05, Christian Gütschow wrote:
>     > Dear Rivet authors,
>     >
>     > I'm just trying to implement a Rivet routine for a W+b ATLAS
>     measurement
>     > and was wondering what the preferred way of doing particle-level
>     > b-tagging in Rivet is?
>     >
>     > Naively, I would think that the easiest way to decide whether a
>     jet is a
>     > b-jet is to use the HeavyHadrons projection, e.g. like so
>     >
>     >     addProjection(HeavyHadrons(-2.5, 2.5, 5.0*GeV), "BHadrons");
>     >     ...
>     >     const Particles& bHadrons = applyProjection<HeavyHadrons>(event,
>     >     "BHadrons").bHadrons();
>     >     ...
>     >     // for each jet "j":
>     >     foreach(const Particle& b, bHadrons) {
>     >       if( (b.pT() > 5.0*GeV) && (deltaR(j, b) < 0.3) ) {
>     >         // jet matched to B hadron!
>     >         ...
>     >         break;
>     >       }
>     >     }
>     >
>     >
>     > Turns out, this doesn't do anything at all because bHadrons has always
>     > size 0 for some reason. Is this to be expected or likely to be
>     some sort
>     > of bug (on my side)?
>     >
>     > On the other hand, if I use the approach that was used in the Z+b(b)
>     > analysis (ATLAS_2014_I1306294), i.e. something like
>     >
>     >     bool hasB = false;
>     >
>     >     foreach(const GenParticle* b, particles(event.genEvent())) {
>     >       if(b->momentum().perp() < 5.0*GeV)  continue;
>     >       for(uint k=0; k < stableB.size(); ++k) {
>     >         if( fabs(b->pdg_id()) == stableB[k] ) {
>     >           if( deltaR(j.momentum().eta(), j.momentum().phi(),
>     >     b->momentum().eta(), b->momentum().phi()) < 0.3 ) {
>     >             // jet matched to B hadron!
>     >             hasB = true;
>     >             break;
>     >           }
>     >         }
>     >       }
>     >       if(hasB)  break;
>     >     }
>     >
>     >
>     > where stableB is a custom-made vector of the B-hadron PDG IDs,
>     then I do
>     > find the B hadrons in the event and can successfully match my jets
>     to them.
>     >
>     > I think it's safe to say that while the latter option does the
>     trick, it
>     > is a bit of an awkward way to code this up. (Presumably that's the
>     > reason why the Z+b(b) analysis is still dwelling in the contributions
>     > area...?) Is there a better way of doing this?
>     >
>     > Many thanks for your advice in advance!
>     >
>     > Cheers,
>     > Chris
>     >
>     > --
>     >
>     >  Dr. Christian Gütschow
>     >
>     >  TU Dresden
>     >  Institut für Kern- und Teilchenphysik
>     >  Zellescher Weg 19
>     >  01069 Dresden
>     >
>     >  > E17, Andreas-Schubert-Bau
>     >  > chris.g at cern.ch <mailto:chris.g at cern.ch>
>     <mailto:chris.g at cern.ch <mailto:chris.g at cern.ch>>
>     >
>     >
>     >
>     > _______________________________________________
>     > Rivet mailing list
>     > Rivet at projects.hepforge.org <mailto:Rivet at projects.hepforge.org>
>     > https://www.hepforge.org/lists/listinfo/rivet
>     >
> 
> 
>     --
>     Dr Andy Buckley, Royal Society University Research Fellow
>     Particle Physics Expt Group, University of Glasgow / PH Dept, CERN
> 
> 
> 
> 
> -- 
> 
>  Dr. Christian Gütschow
> 
>  TU Dresden
>  Institut für Kern- und Teilchenphysik
>  Zellescher Weg 19
>  01069 Dresden
> 
>  > E17, Andreas-Schubert-Bau 
>  > chris.g at cern.ch <mailto:chris.g at cern.ch>
> 


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