Reco on demand not finding products in the file
The problem is illustrated by my current ArtExample package. In is in FNALU afs space ~kutschke/ArtExample_v4.tar.gz
To execute the examples:
tar xzf ArtExample_v4.tar.gz
cmake -DCMAKE_BUILD_TYPE=Debug $ARTEXAMPLE_SOURCE
FHICL_FILE_PATH includes ../ArtExample/HelloWorld/fcl which is where the fcl files live.
To illustrate the bug:
mu2e -c makehits.fcl >& log.1
mu2e -c readhits.fcl >& log.2
mu2e -c readhits2.fcl >& log.3
mu2e -c readhits4.fcl >& log.4
mu2e -c readhits5.fcl >& log.5
The bug is illustrated in log.5
- Run two producers and one analyzer that checks products made by the producers. Also write a file. Use scheduled reco.
- Read from the file made in makehits.fcl. Just run the analyzer.
- This is makehits.fcl but done with reco on demand. Does not make the output file.
- Repeat of readhits2.fcl but use variants on the modules that have extra printout turned on.
( I will redo this to select severity levels at run time instead of using different modules.)
- Also add an unrelated producer just to see what happens.
- Questions: How does the code know to call the c'tor of MakeParticles2 and MakeHits2 before ever receiving a request for particles or hits?
How does the code know to never construct an instance of Test?
- This is a repeat of readhits4.fcl but, instead of the source EmptyEvent, it reads events from the file made by makehits.fcl
- It also makes an output file.
- The producers are still specified and reco on demand is enabled.
- I expected that art would discover that the products are available in the event and would not run the producers. But it does run the producers.
- I inspected the output event-data file and I see that both sets of data products are present in the event.
- I tried renaming the process name of readhits5 to makehits but it gave a run time error since that process name is already found in the input file.
#1 Updated by Marc Paterno almost 10 years ago
- Status changed from New to Feedback
The behavior you describe is actually the behavior that is intended under the current design.
In order to allow re-building of existing (and presumably incorrect) reconstruction products, the presence of an
EDProducer that can produce a product of type
X with label
y takes precedence over the existence over the output of such a producer already present in the input file.
In order to obtain what is arguably a more natural "give me what's in the Event, and if there isn't one there make one like this" semantic to on-demand reconstruction, while still allowing the forced reconstruction of "bad" products, we need to introduce a "drop products on input" facility into the framework. We do not yet have a facility to do this is a complete enough fashion.
We should discuss the priority of this issue, probably at this week's stakeholder meeting.