Project

General

Profile

Feature #2967

cet::map_vector support for FindMany and View

Added by Andrei Gaponenko about 7 years ago. Updated over 4 years ago.

Status:
Closed
Priority:
Normal
Category:
Navigation
Target version:
Start date:
09/14/2012
Due date:
09/30/2013
% Done:

100%

Estimated time:
24.00 h
Spent time:
Scope:
Internal
Experiment:
Mu2e
SSI Package:
art
Duration: 382

Description

Hello,

Having prepared an association object

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

I can perform queries "by cluster", creating

    art::FindMany<SimParticle,ExtMonFNALRecoClusterTruthBits>
        r2t(ih, event, art::InputTag(truthModuleLabel_, truthInstanceName_));

However an attempt to query "by particle"

    art::FindMany<ExtMonFNALRecoCluster,ExtMonFNALRecoClusterTruthBits>
        t2r(ih, event, art::InputTag(truthModuleLabel_, truthInstanceName_));

fails because FindMany code is looking for an object of type

art::Assns<std::pair<cet::map_vector_key,mu2e::SimParticle>,mu2e::ExtMonFNALRecoCluster,mu2e::ExtMonFNALRecoClusterTruthBits>

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,
Andrei

History

#1 Updated by Christopher Green over 6 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 over 5 years ago

  • Target version changed from 1.09.00 to 521

#3 Updated by Christopher Green about 5 years ago

  • Target version changed from 521 to 1.13.00

#4 Updated by Christopher Green almost 5 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 over 4 years ago

  • Assignee set to Christopher Green

#6 Updated by Christopher Green over 4 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 over 4 years ago

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

#8 Updated by Kyle Knoepfel over 4 years ago

  • Status changed from Resolved to Closed


Also available in: Atom PDF