Feature #18990

Function to return a list of compatible data products

Added by Bruce Baller about 3 years ago. Updated about 3 years ago.

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


Estimated time:
Spent time:



Sorry that I missed your talk at the LArSoft meeting yesterday. I looked at your slides and the example and would have asked you some questions about this which are related to the problem I found yesterday.

I re-processed my standard set of 400 BNB events with cosmic removal yesterday and found that the performance was worse than it used to be. After some fumbling around I realized that I had changed the HitTruthModuleLabel to “crHitRemoval” to process the nue event that you told me about and forgot to change it back to "pandoraCosmicHitRemoval". The Hit – MCParticle associations were being made between different sets of products. This would have become more apparent sooner if an exception had been thrown. I think that it is possible to check for an incompatibility using the data product ID but haven’t figured out how to do that.

This highlights what I think is a general problem in that the user needs to know the module label names for the compatible data products. In your RecoProxyUsageExample, the user needs to know trktag, vtxtag and mcstag. In the case of Hits and Hit – MCParticles and Hit - Wire assns the association should be one-to-one. It would be nice if there was a function that returns a vector of handles of associations with compatible data products, presumably by comparing the product IDs. The code would then have to decide what to do if there is more than one. If for example there is one track collection and two different vertex modules were used on that collection, one would get two vertex handles if you passed this function the track collection handle. You would get one track handle if you passed it a vertex collection handle.

Let me know if this is a flawed idea.


#1 Updated by Lynn Garren about 3 years ago

  • Status changed from New to Under Discussion
  • Assignee set to Katherine Lato
  • Target version set to 2018-2-quarter

Katherine, will you please set an agenda for this? Remind us for the second quarter.

#2 Updated by Giuseppe Cerati about 3 years ago

For the record, this was the reply I gave to this email:

I do not know if there are functionalities that return all associations between objects of two definite types.

On the other hand, if you retrieve an art::Ptr from the association, you could check that the ProductID matches the one of the collection you are using.
So you could throw an exception if they do not match. Maybe it is not too difficult to create a method that does this for you.
However, there could always be more than one association between the same two collection (e.g with different association criteria), so you'll always need the input tag I think.

And Gianluca's follow up:

There is one way, but you still have to real all the associations of the same type, when you need only one, and in principle the logic to choose
which one might be tricky. On top of that, is is not clear whether asking all the associations between L and R will return also those which have any metadata.

I won't correct Giuseppe, but rather say that what Bruce describes goes beyond the framework facilities and straight into LArSoft conventions.
Erica loves to talk about things like that, that boil down into having information of which data products should be used together.

Bruce, why don't you turn this e-mail in a feature request?

#3 Updated by Katherine Lato about 3 years ago

Okay, I'll set something up with Gianluca, Giuseppe and Erica to come up with a proposal, then possibly another meeting with Bruce to discuss it.

#4 Updated by Gianluca Petrillo about 3 years ago

Erica, Giuseppe, Gianluca and Katherine discussed the specific and the more general issue.
Different levels of solutions are possible.

  1. a free function returning all the association data products between the two desired classes (e.g. all art::Assns<recob::Hit, simb::MCParticle> data products)
  2. a registry in the event listing all the association data products between the two desired classes, and functions to access that registry
  3. more complex solutions have also been mentioned, down to a global list of preferred data products
Option (1) is fairly straightforward to implement within the current art and LArSoft, and it is in essence the request in this ticket.
Option (2) is more complex, but it allows for further developments. For example, it would allow:
  • to connect data products without associations (e.g. tracks and their reconstructed momenta stored as two separate data products with the "parallel collection" assumptions)
  • special labels to tag data products (e.g. crossSectionRecommended)

Note that neither of these options is necessarily gallery-compatible.

#5 Updated by Gianluca Petrillo about 3 years ago

  • % Done changed from 0 to 10

#6 Updated by Katherine Lato about 3 years ago

  • Assignee changed from Katherine Lato to Erica Snider

Also available in: Atom PDF