Feature #2967

cet::map_vector support for FindMany and View

Added by Andrei Gaponenko over 8 years ago. Updated about 6 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
24.00 h
Spent time:
SSI Package:
Duration: 382



Having prepared an association object

typedef art::Assns<SimParticle,ExtMonFNALRecoCluster,ExtMonFNALRecoClusterTruthBits> ExtMonFNALRecoClusterTruthAssn;

I can perform queries "by cluster", creating

        r2t(ih, event, art::InputTag(truthModuleLabel_, truthInstanceName_));

However an attempt to query "by particle"

        t2r(ih, event, art::InputTag(truthModuleLabel_, truthInstanceName_));

fails because FindMany code is looking for an object of type


The problem is caused by the fact that mu2e::SimParticleCollection is
not an std::vector but

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

Can please FindMany and related templates be specialized for
cet::map_vector to enable convenient queries involving mu2e SimParticles?

Chris mentioned that View may also need to deal with map_vector in a
special way.

Thank you,


#1 Updated by Christopher Green over 7 years ago

  • Due date set to 09/30/2013
  • Category set to Navigation
  • Status changed from New to Accepted
  • Target version set to 1.09.00
  • Estimated time set to 24.00 h
  • Scope set to Internal
  • Experiment Mu2e added
  • SSI Package art added

It is unclear without some further analysis whether the solution is in fact a specialization of FindMany or a related helper, or more involved. The above estimate assumes that the solution is indeed a specialization, and all bets are off if this turns out not to be the case.

#2 Updated by Christopher Green about 7 years ago

  • Target version changed from 1.09.00 to 521

#3 Updated by Christopher Green over 6 years ago

  • Target version changed from 521 to 1.13.00

#4 Updated by Christopher Green about 6 years ago

  • Target version changed from 1.13.00 to 1.14.00

Due to the accelerated timescale for version:"Sirius A", this issue must be deferred to a subsequent release.

#5 Updated by Christopher Green about 6 years ago

  • Assignee set to Christopher Green

#6 Updated by Christopher Green about 6 years ago

  • Status changed from Accepted to Feedback
  • % Done changed from 0 to 70

According to tests on the current version of art, FindXXX{,P} on an Assns where one of the collections is a cet::map_vector appears to work without issue. Please try again and see if your originally-reported issue is still a problem for you.

The utility of an art::View into a cet::map_vector is less obvious after careful thought, because there may be information loss and failure of exiting code on existing data files. One could decide to allow filling an art::View<std::pair<cet::map_vector_key, X>, which is trivial but may not have many use cases; and / or one could allow the filling of an art::View<X>, but then the key for each item would be lost. This may be what the user wants, but using the version of art that implemented this may cause code to fail to read an existing data file since, instead of (say) one collection (an std::vector<X>, say) with a given module label being able to satisfy a getView() request, one now may have two (a cet::map_vector<X> with the same module and instance label would also satsfy), causing an ambiguity and therefore a failure. I'm a little hesitant to implement this without a clearly stated request that the feature is wanted.

#7 Updated by Christopher Green about 6 years ago

  • Status changed from Feedback to Resolved
  • % Done changed from 70 to 100

#8 Updated by Kyle Knoepfel about 6 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF