Project

General

Profile

Feature #1361

A request to extend Ptr

Added by Rob Kutschke almost 9 years ago. Updated almost 9 years ago.

Status:
Closed
Priority:
Normal
Category:
Navigation
Target version:
Start date:
06/10/2011
Due date:
% Done:

100%

Estimated time:
12.00 h
Scope:
Internal
Experiment:
-
SSI Package:
Duration:

Description

I would like to get rid of some redundant data in some of the mu2e persistent data product classes but to do so I need additional interface for Ptr. The simplest example is the class MCDataProducts/inc/StepPointMC.hh, which contains two data members that record the same information.

cet::map_vector_key   _trackId;
art::Ptr<SimParticle> _track;

When a StepPointMC is created it records an identifier, _trackId of the track that created it. This identifier is a key into another data product of type:

typedef cet::map_vector<mu2e::SimParticle> SimParticleCollection;

StepPointMC also contains a Ptr to the same information, the data member _track: Why do I have both? Because, as each StepPointMC object is created, I have all of the information needed to construct _trackId but I am missing some of the information needed to construct _track, namely a handle to the SimParticleCollection. I am missing the handle because the same module creates all of SimParticleCollection and several instances of StepPointMCCollection.

After G4 has finished processing one event, I add the SimParticleCollection to the event and get back an orphan handle. Then I loop over all StepPointMC objects
and set the Ptrs, using the orphan handle and the data member _trackId.

Once the Ptr has been set, I no longer need trackId and I could replace the accessors that use trackId to, instead, use _track.key() and _track.isNonnull().

If Ptr had a two phase constructor then I could eliminate the member _trackId - I could set the offset in the c'tor of StepPointMC and then I could complete the construction after a handle is available. I am sure that there are other, more robust solutions.

There are similar issues in the class SimParticle. In that class there are two pairs of redundant members:

key_type _parentId;
art::Ptr<SimParticle> _parentSim;
std::vector<key_type>  _daughterIds;
std::vector<art::Ptr<SimParticle> > _daughterSims;

This class as the additional complication that the pointees are in the same data product as the Ptrs.

Rob

Related issues

Related to art - Feature #1363: Ptr's back into the same containerClosed06/10/2011

Related to art - Bug #1364: Ptr's back to the same container - and mixingClosed06/10/2011

Associated revisions

Revision 8529e51f (diff)
Added by Christopher Green almost 9 years ago

Implement solution for issue #1361, issue #1363 and issue #1364.

History

#1 Updated by Christopher Green almost 9 years ago

  • Category set to Navigation
  • Status changed from New to Resolved
  • Assignee set to Christopher Green
  • Target version set to 0.07.10
  • % Done changed from 0 to 100
  • Estimated time set to 12.00 h

Solution implemented with 8529e51. From the event loop (produces() or filter()) do:

getProductID<PROD>(e)
or
getProductID<PROD>(e, instanceName)
(see source:test/Integration/ProductIDGetter_module.cc) and then crate a Ptr<PROD> using the Ptr(ProductID const &id, key_type offset, ProductGetter const *getter) signature (use e.productGetter() for the final argument).

#2 Updated by Marc Paterno almost 9 years ago

  • Status changed from Resolved to Closed


Also available in: Atom PDF