[Rivet] New analysis: ATLAS_2012_I1094061

[Andy Buckley]

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.