Project

General

Profile

Support #19143

event.get method acting unexpectedly

Added by Raymond Culbertson about 3 years ago. Updated about 3 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Navigation
Target version:
-
Start date:
02/26/2018
Due date:
% Done:

100%

Estimated time:
Scope:
Internal
Experiment:
Mu2e
SSI Package:
art
Duration:

Description

We have a new piece of code which calls
event.get(ProductID const pid, Handle<PROD>& result)
which gives an error:
but an attempt to interpret it as an object of type 'mu2e::DummyProduct' failed.
As best as we can determine, the product is present
and it can be accessed without error using getByLabel and getManyByType.
Below is the full error message and how to reproduce it.

source /cvmfs/fermilab.opensciencegrid.org/products/common/etc/setups
setup mu2e
git clone ssh:///cvs/projects/mu2eofflinesoftwaremu2eoffline/Offline.git
cd Offline
git checkout debug-weird-handle-bug
source setup.sh
scons -j 20

  1. write out the bad file
    mu2e -c Sandbox/test/dummyProductBag_write.fcl
  2. read the file, call event.get
    mu2e -c Sandbox/test/dummyProductBag_read.fcl -s dummyProductBag.art

reproducible error:
---- LogicError BEGIN
Product retrieval via Handle<T> succeeded for product:
Branch Type = Event
Process Name = WriteDummyProductBag
ModuleLabel = value
Product ID = 2377898492
Class Name = mu2e::DummyProduct
Friendly Class Name = mu2e::DummyProduct
Product Instance Name =
but an attempt to interpret it as an object of type 'mu2e::DummyProduct' failed.
cet::exception going through module AnalyzeDummyProductBag/readProdBag run: 1 subRun: 0 event: 1
---- LogicError END


Related issues

Related to art - Feature #18979: Retrieve art::InputTag by art::ProductIDClosed02/12/2018

Related to art - Feature #19306: create Ptr to productAccepted03/07/2018

History

#1 Updated by Kyle Knoepfel about 3 years ago

  • Tracker changed from Bug to Support
  • Status changed from New to Feedback

The behavior you observe is the expected behavior: the art::Event::get by ProductID function is intended to retrieve products that have already been read from the input file [1] (or are already in memory via e.g. art::Event::getBy*). In fact, this exact issue came up a few weeks ago (see the related issue linked to below). Our first question is why do you need to read a product into memory using art::Event::get instead of through the typical getBy* interface?

1 We will update the documentation to better explain the difference in behavior.

#2 Updated by Raymond Culbertson about 3 years ago

The new product contains a list of products that are logically associated.
We wanted to put a list of the products in the event as a product as
a convenience to the user since the complete list of products and how they
are related can get confusing. We expected a reasonable approach would
be to save the product ID's, and then retrieve them based on the ID.
So is this illogical? Should use provenance to find an input tag,
save the inputtag in the list and retrieve by getByLabel?

I don't see the other issue link.

#3 Updated by Kyle Knoepfel about 3 years ago

  • Related to Feature #18979: Retrieve art::InputTag by art::ProductID added

#4 Updated by Kyle Knoepfel about 3 years ago

Your use case seems sensible. It seems to me that the better solution may be for art to provide an art::Ptr<T> that can point to a product instead of an element inside of a data product. Do you agree? If so, then I ask for a separate feature request for art::Ptr<T>.

In the meantime, storing the art::InputTag and calling art::Event::getByLabel is probably your best bet. We can also discuss at this week's stakeholders meeting whether switching the behavior of art::Event::get to actually retrieve products is acceptable.

#5 Updated by Raymond Culbertson about 3 years ago

When starting on the problem, one of the first questions was
why is there no art::Ptr<T>? So I guess that is the
most intuitive solution. We have had other discussions where
this could be used. I will put in a request.
Since it seems we will not be using Event::get, I guess I
don't have a opinion on its behavior. If I were to comment,
I would suggest, if not too hard, to allow retrieving the product,
or as a second choice, rename it getFromMemory or similar.

#6 Updated by Raymond Culbertson about 3 years ago

A comment from the original user.. He observed that Event::get()
still failed after the relevant product had been returned by getManyByType.
According to my understanding of your explanation, getManyByType
should have moved the products into memory and let Event::get() succeed.
Does that make sense?

#7 Updated by Kyle Knoepfel about 3 years ago

  • Category set to Navigation
  • Status changed from Feedback to Closed
  • Assignee set to Kyle Knoepfel
  • % Done changed from 0 to 100

According to my understanding of your explanation, getManyByType should have moved the products into memory and let Event::get() succeed.

That is correct. If there is a reproducible example that demonstrates contrary behavior, please file a bug report.

#8 Updated by Kyle Knoepfel about 3 years ago

Also available in: Atom PDF