[Rivet] lifetimes in rivet

[Jonathan Butterworth]

Hi all,

The question originated from a dicussion between me and Alex.

I think a confusion has crept in. We are talking about the lifetime for 
a species, not how long a particular instance of a particle lasts. So it 
is basically the question of whether a rivet analysis can specify which 
particles should be considered stable or not, or whether this has to be 
done (as at present) in each generator configuration. I don't the actual 
decay vertex is relevant.

I suspect that one could build a variant of the final state projection 
which studied the decay history, and if certain particles which should 
have been "stable" has been decayed by the generator, removed their 
decay products and added back the original. However, there's no way 
rivet could do the opposite (i.e. decay a particle which should have 
been decayed but which the generator left stable). At best it could flag 
up an error "particle should have been decayed according to the lifetime 
criteria of this analysis, but wasn't"

So whether it is actually worth the work to do what can only be an 
incomplete job, I don't know. There is also the limitation that we 
really do NOT want people declaring a Z or a rho stable for instance.
We are really just talking about particles that actually travel some 
distance. Basically muons, taus (?) and weakly-decaying hadrons.

My guess is this is not a priority at the moment and we should just make 
sure the generator configs are right.

Cheers,
Jon


Andy Buckley wrote:
> On 03/04/10 18:09, Frank Siegert wrote:
>> Andy Buckley, Saturday 03 April 2010:
>>> On 01/04/10 09:43, Alexander Richards wrote:
>>>> Was wondering if there was a nice Rivety was of cutting of particle
>>>> lifetimes such as a lifetime projection or something? I think I can
>>>> directly get the lifetime of the particles from the GenParticle but
>>>> was wondering if there was an easier way?
>>> (Copying to Rivet list: please send to the list if possible!)
>>>
>>> I don't *think* there is a way to get the generator's take on the
>>> lifetime from the GenParticle: at least, I don't see anything in the
>>> GenParticle interface that does this. HepPDT could probably be used to
>>> get this info from the PID, but there's no guarantee that the number
>>> matches that used by the generator.
>>>
>>> If there is such a mechanism in HepMC (and it's used, including in the
>>> translation from the Fortran HEPEVT event record), then I'd be very
>>> happy: we could move a lot of restrictions on particle lifetime cuts
>>> from how the generator has to be configured into the Rivet analysis
>>> code, and a lifetime-sensitive projection of some sort would indeed be
>>> useful. But I don't know of such a mechanism: maybe someone can correct
>>>  me?
>> It should be relatively easy (and proper) to do this from the vertex 
>> offset in combination with the incoming momentum. At least that must be 
>> how the experiments do it when they run a Monte-Carlo, since there is no 
>> separate (duplicate) storage of "generated life time".
> 
> That's true... but do all generators write in microscopically displaced
> vertices as part of their hadron decays? K and B particles yes, but others?
> 
> My only experimental interaction with lifetimes has been in placing the
> generator level lifetime cut to keep certain G4-handled particles stable
> at gen level, but I guess someone will be wanting to know what the true
> lifetime of a particular particle was.
> 
> Anyway, if this turns out to be reliable enough, then we could provide a
> convenience method on Rivet::Particle -- and a projection if there is a
> demand for filtering on lifetimes.
> 
> Andy
> 

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Prof. Jonathan Butterworth,              http://www.hep.ucl.ac.uk/~jmb/
Physics and Astronomy Department                  Tel: +44 20 7679 3444
ATLAS, CERN                                       Tel: +41 22 76  72340
University College London                 Gower St, London WC1E 6BT, UK
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~