Support #16152

Can't create art::Ptr<T> from gallery::Handle or gallery::ValidHandle

Added by Corey Adams over 3 years ago. Updated over 2 years ago.

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


Estimated time:
Spent time:
SSI Package:


Hi again,

I am trying to make some larsoft code portable into gallery. I am stuck on what appears to be a missing piece from gallery that's available in full blown art.

The following code works in larsoft:

art::InputTag _input_tag(label);
art::Handle< std::vector<recob::Hit> > theHits;
evt.getByLabel(_input_tag, theHits);

if (!theHits.isValid())
    // mf::LogDebug("LArPandora") << "  Failed to find hits... " << std::endl;
    // mf::LogDebug("LArPandora") << "  Found: " << theHits->size() << " Hits " << std::endl;

for (unsigned int i = 0; i < theHits->size(); ++i)
    const art::Ptr<recob::Hit> hit(theHits, i);

But, when I port it to gallery (art::Handle -> gallery::Handle) it complains:

LArPandoraHelper.cxx:47:59: warning: unused parameter ‘evt’ [-Wunused-parameter]
 void LArPandoraHelper::CollectWires(const gallery::Event &evt,
In file included from /data/products/larsoft/canvas/v1_05_01/include/canvas/Persistency/Common/Assns.h:82:0,
                 from /data/products/larsoft/canvas/v1_05_01/include/canvas/Persistency/Common/detail/IPRHelper.h:7,
                 from /data/products/larsoft/canvas/v1_05_01/include/canvas/Persistency/Common/FindManyP.h:124,
                 from LArPandoraHelper.cxx:14:
/data/products/larsoft/canvas/v1_05_01/include/canvas/Persistency/Common/Ptr.h: In instantiation of ‘art::Ptr<T>::Ptr(const H&, art::Ptr<T>::key_type) [with H = gallery::Handle<std::vector<recob::Wire> >; T = recob::Wire; art::Ptr<T>::key_type = long unsigned int]’:
LArPandoraHelper.cxx:68:53:   required from here
/data/products/larsoft/canvas/v1_05_01/include/canvas/Persistency/Common/Ptr.h:262:11: error: ‘const class gallery::Handle<std::vector<recob::Wire> >’ has no member named ‘id’
/data/products/larsoft/canvas/v1_05_01/include/canvas/Persistency/Common/Ptr.h: In instantiation of ‘art::Ptr<T>::Ptr(const H&, art::Ptr<T>::key_type) [with H = gallery::Handle<std::vector<recob::Hit> >; T = recob::Hit; art::Ptr<T>::key_type = long unsigned int]’:
LArPandoraHelper.cxx:96:50:   required from here
/data/products/larsoft/canvas/v1_05_01/include/canvas/Persistency/Common/Ptr.h:262:11: error: ‘const class gallery::Handle<std::vector<recob::Hit> >’ has no member named ‘id’

It appears the Handle (and ValidHandle, I tried that first) class in gallery is missing the id member. Is there a work around for this, or is this a bug that needs to be fixed?



#1 Updated by Kyle Knoepfel over 3 years ago

  • Description updated (diff)

#2 Updated by Kyle Knoepfel over 3 years ago

  • Status changed from New to Accepted
  • Assignee set to Marc Paterno

This appears to be an omission from the gallery feature list. We will implement it. Estimated time to be determined.

#3 Updated by Marc Paterno over 3 years ago

  • Status changed from Accepted to Feedback

The reason that the gallery handle templates (both Handle and ValidHandle) do not allow for creation of art::Ptr objects is that neither have the metadata (the ProductID) necessary for the construction of a Ptr.

After analysis, adding this metadata to gallery's handles would make reading of art/ROOT files in gallery significantly slower, and so we are disinclined to make this change.

If the consensus among the experiments is that the slowdown (our guess is a factor of two, but that is just a guess) is worthwhile, we could implement the necessary features.

As additional information, the CMS "FWLite" (to which gallery is related) does not support this, for the same reason as gallery does not: the speed hit is too great.

Please let us know if you wish to take up the issue among the experiments. If you wish, we could schedule time for you to present a case at an upcoming stakeholder meeting.

#4 Updated by Kyle Knoepfel over 2 years ago

  • Tracker changed from Bug to Support
  • Status changed from Feedback to Closed
  • SSI Package gallery added

Closed due to Marc's explanation in #16152-3. If additional assistance is needed in determining a path forward for handling this type of use case, please open another issue.

Also available in: Atom PDF