[Rivet] New analysis: ATLAS_2012_I1094061

[Andy Buckley]

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 Andy Buckley, Royal Society University Research Fellow
Particle Physics Expt Group, University of Edinburgh

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.