[Rivet] New analysis: ATLAS_2012_I1094061

[Ben Waugh]

Hi Andy,

FWIW, from someone who has spent more time recently dealing with 
Rivet-based undergraduate project than working with it myself, something 
like this would be a Good Thing.

Weaning experimentalists off "measuring" parton-level cross sections is 
definitely necessary, but B-hadrons and taus are definitely much nearer 
the "real" end of the spectrum, and there should really be a recommended 
way of dealing with them. Providing a recipe would be one approach, but 
some built-in and well tested functionality would be even better.

Cheers,
Ben

On 22/03/13 10:19, Andy Buckley wrote:
> Any more feedback/thoughts on this? On reflection I think a
> Particle::fromDecay() method is a physically safe thing to do by the
> HepMC status standard -- whether it's *appropriate* depends on the
> circumstances, but we can say the same about pretty much any
> functionality in Rivet.
>
> And if people are going to do this anyway (or moan about not being able
> to) then I'd prefer that we provide a pre-existing function that we have
> control over, rather than receive 10 differently broken variants on
> HepMC ancestor looping in submitted analyses :)
>
> Here is an "external" (i.e. not a Particle method) version that I cooked
> up earlier this week, for playing with HepMC truth filtering:
>
> /// @brief Determine whether the particle is from a hadron or tau decay
> ///
> /// Specifically, walk up the ancestor chain until a status 2 hadron or
> /// tau is found, if at all.
> ///
> /// @note This question is valid in MC, but may not be answerable
> /// experimentally -- use this function with care when replicating
> /// experimental analyses!
> inline bool fromDecay(const GenParticle* p) {
>    /// @todo *sigh* HepMC constness mess forces this cast...
>    HepMC::GenVertex* gv = \
>      const_cast<HepMC::GenVertex*>(p->production_vertex());
>    if (gv == NULL) return false;
>    /// @todo HepMC needs const versions of these iterator methods :-/
>    for (HepMC::GenVertex::particle_iterator pi = \
>         gv->particles_begin(HepMC::ancestors); \
>         pi != gv->particles_end(HepMC::ancestors); ++pi) {
>      const GenParticle* p2 = *pi;
>      if (p2->status() == 2 && (HepPID::isHadron(p2->pdg_id()) || \
>          abs(p2->pdg_id()) == 15)) return true;
>    }
>    return false;
> }
>
> (This can be cleaned up substantially when some HepMC bugs are ironed
> out... hopefully soon, in fact.)
>
> So, can I add a variant of this to the 1.8.3 branch and push out a beta
> for testing in mcplots? Or are there still concerns?
>
> Thanks,
> Andy
>
>
> On 15/03/13 14:37, Andy Buckley wrote:
>> Hi David,
>>
>> There's not been any "intentional" trend to soften our analysis
>> requirements: what did you have in mind?
>>
>> I think this opens some interesting considerations, though... and I
>> apologise for a slightly long email that results. As I see it we have 3
>> or 4 classes of analysis possible in Rivet:
>>
>> a) analysis based on status 1 only, typically flavour-blind
>>
>> b) analysis based on status 1 and status 2 to short-circuit
>> long/impossible work on exactly reconstructing decayed hadrons as in the
>> experiment
>>
>> c) analysis based on status 1 and status 2, but also using the status 2
>> to ask some questions that can't (at least not at all easily) be
>> answered experimentally
>>
>> d) analyses using status 3, 11, whatever. We don't accept these. Let's
>> not talk about them ever again ;-)
>>
>> The (a) analyses are totally uncontroversial and good. The (b) analyses
>> are fine provided the experimental data have been corrected for the
>> efficiencies and purities introduced in the K/B/Upsilon/etc. reco... but
>> I think we really need to provide a high-level interface for examining
>> decay chains, to avoid the sort of recursive GenEvent spaghetti that I
>> just had to wade through in Peter's BaBar/Belle/ARGUS analyses!
>>
>> This proposed extra function on Particle is potentially a high-level
>> enabler for the (c) analyses: in general there is no experimental way to
>> tell if a muon isn't "prompt" if it comes from an undisplaced hadron
>> decay. But for b-hadron semi-leptonic decays I think we can argue that
>> there could be an experimental handle on this via displaced vertices...
>> and hence I think it deserves promotion to the Rivet API*. The
>> alternative, as I see it, is either analyses that are wrong, or which
>> are full of more HepMC-accessing spaghetti.
>>
>> So maybe I *am* arguing that some softening is pragmatically necessary:
>> we are still streets ahead of the experiments in the level of
>> physicality that we enforce, and I think that approach *is* having an
>> impact as more experimentalists come into contact with Rivet. But if we
>> don't help them to do things like this which *can* be appropriate, we'll
>> just annoy them and lose users/influence. I'd certainly rather that
>> people test for promptness this way rather than the more usual "look for
>> status = 3 if Pythia6, status 62 if Pythia8, etc. etc." rules that get
>> passed around (at least in ATLAS and I assume in other experiments too).
>> In my ideal world the students who see a safe and portable way to do it
>> in Rivet will start asking why the experiment is still doing something
>> dodgy... and I think this grassroots way will have more impact than me
>> playing my same old "don't unfold to partons" broken record ;-)
>>
>> Andy
>>
>> [*] I'm also going to advocate some version of Particle::prodPos() to
>> allow an easy version of this displacement testing. I think
>> Particle::decayPos() needs to wait until a more full-featured decay
>> chain helper is in place, since there are too many ways to shoot
>> yourself with the current handling of unstable particles in Rivet.
>>
>>
>> On 14/03/13 22:09, David Grellscheid wrote:
>>> Hi Andy,
>>>
>>> without having time to think about this particular issue, I'm a bit wary
>>> of the recent trend of softening the 'hepmc-code-1-only' feature Rivet
>>> has. More and more of these requests are coming in, and I think we
>>> should try to define quite clearly what is OK and what isn't.
>>>
>>>    David
>>>
>>>
>>>
>>>
>>> On 14/03/2013 17:39, Andy Buckley wrote:
>>>> < ~ topic change/>
>>>>
>>>> Once this is in, my only blocker for the 1.8.3 mcplots-testing to start
>>>> (and the release asap after) is that I'd like to add a bool
>>>> Particle::fromDecay() method, to return true if a status 2 hadron or tau
>>>> is found in the particle's ancestor list. This is a limited version of
>>>> the isPrompt() method that I'd like to have in general to distinguish
>>>> particles (particularly leptons and photons) resulting from hadron
>>>> decays and QED FSR from those from the primary interaction*. Will Bell
>>>> asked me for some way to exclude muons from semi-leptonic b decays when
>>>> looking for leptonic W decay products, and I've had in mind for a while
>>>> that this is a safe and sensible way to do it.
>>>>
>>>> Ok with everyone? I'll put it in both the AIDA branch and the YODA
>>>> trunk... 2.0.0b1 coming as soon as I've done a few YODA tweaks and
>>>> checked/ensured that the installation isn't a nightmare on lxplus.
>>>>
>>>> Andy
>>>>
>>>> [*] I don't want to say "hard process" because I don't know how or if
>>>> MPI-associated particles can/should be distinguished: probably not.
>>>>
>>>>
>>>> On 14/03/13 17:39, Andy Buckley wrote:
>>>>> Thanks! Can you add it by yourself, James? And do you want to check the
>>>>> stylistic correctness of your own code? ;-)
>>>>>
>>>>> For others here, and a degree of archiving, it'd be handy if you could
>>>>> post a URL to your validation plots.
>>>>>
>>>>> Cheers,
>>>>> Andy
>>>>>
>>>>>
>>>>> On 14/03/13 16:01, James Monk wrote:
>>>>>> Hi Riveteers,
>>>>>>
>>>>>> With my ATLAS hat on now, we'd like to add a new analysis for the
>>>>>> ATLAS two-particle correlation, ATLAS_2012_I1094061.  I can submit
>>>>>> the code directly to the Rivet aida svn branch, or send a tarball if
>>>>>> you'd prefer to inspect it first.
>>>>>>
>>>>>> cheers,
>>>>>>
>>>>>> James
>>>>>>
>>>>>> _______________________________________________
>>>>>> Rivet mailing list
>>>>>> Rivet at projects.hepforge.org
>>>>>> http://www.hepforge.org/lists/listinfo/rivet
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>
>

-- 
Dr Ben Waugh                                   Tel. +44 (0)20 7679 7223
Dept of Physics and Astronomy                  Internal: 37223
University College London
London WC1E 6BT