[Rivet] Finding GenParticles without a production vertex

[Andy Buckley]

Hi Kiran,

Sorry for the delayed reply... this sounded serious and we wanted to
look at it properly.

It seemed strange because there is no copying of the GenEvent itself --
the (const) pointer to it is copied between Rivet::Particle objects as
the Jet is assembled, but they should always point to the same object in
the original record.

Some projections (e.g. the WFinder and ZFinder) create new Particle
objects with no associated GenParticle at all, but of course in that
situation you shouldn't have been able to get a GenParticle *at all*!

I reproduced your experience using your analysis, but an "equivalent"
analysis that I wrote (before noticing that you had attached one!)
looked fine. I've attached my version. Very puzzling, so I stared at the
code a bit... and I think I see the problem -- your analysis contains
lines like the following:

HepMC::GenParticle constituent_g = constituents.at(0).genParticle();

and

HepMC::GenEvent evt = event.genEvent();

In both cases the Rivet Particle::genParticle() method returns a const
GenParticle& or const GenEvent&, i.e. a *reference* to the original
object. Your assigned type, however, is not a reference, and so there is
an implicit copying of the GenParticle. I don't know the details of
HepMC's (often rather crazy) object ownership rules, at least not
without reading through its code, but I suspect that copying a
GenParticle loses the connection to its parent event and associated
vertices.

As it happens, we are approaching the release of the first public
version of Rivet 2.0.0, and I had anyway been wondering if the methods
that access the raw HepMC objects should return pointers rather than
references, both because there may not always *be* a valid GenParticle
inside a Particle (an assumption that was valid a long time ago but not
any more), and also because Rivet is very reference-centric: returning a
pointer may help to signal that you are not in Kansas anymore when you
ask Rivet for access to the raw event record! So it's likely that this
interface will change, and make this mistake less easy in future ;-)

Cheers,
Andy


On 07/02/13 15:29, Kiran Daniel Joshi wrote:
> Dear Rivet developers,
> 
> I'm trying to get access to the GenVertex::position() of the
> constituents of jets, but I'm finding that going through
> Jet::particles() -> Particle::genParticle() provides a GenParticle which
> has no production vertex.
> However when going through event::genEvent() and using
> the HepMC::GenEvent::particle_const_iterator's I get an equivalent
> GenParticle, but also with the production vertex information.
> 
> I've attached a basic analysis which should hopefully describe the issue
> more clearly.
> The output I get from the analysis is:
> 
> Rivet.Analysis.TEST_GENPARTICLE: INFO  GenParticle from Jet::particles() :
> GenParticle: 10575 ID:22
> (P,E)=-0.0322852,-0.00788659,0.0434229,0.0546816 Stat:1 PV:0 EV:0
> Pol:(0,0) F:0
> 
> Rivet.Analysis.TEST_GENPARTICLE: INFO  GenParticle directly from GenEvent:
> GenParticle: 10575 ID:22
> (P,E)=-0.0322852,-0.00788659,0.0434229,0.0546816 Stat:1 PV:-137 EV:0
> Pol:(0,0) F:0
> 
> Where the production vertex (PV) is only filled in the latter case.
> 
> Do you have any idea why this might be happening?
> 
> (I realise that I'm maybe trying to do something that Rivet wasn't
> designed for, but nonetheless I thought it should be possible?)
> 
> Thanks for your help,
> Kiran
> 
> 
> 
> _______________________________________________
> 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: JETVTXTEST.cc
Type: text/x-c++src
Size: 1797 bytes
Desc: not available
URL: <http://www.hepforge.org/lists-archive/rivet/attachments/20130307/db8e91a7/attachment.cc>