Feature #1246
Reco on demand not finding products in the file
0%
Description
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
source /grid/fermiapp/products/mu2e/setupmu2e-art.sh
mkdir build
cd build
. ../ArtExample/ups/setup_for_development
cmake -DCMAKE_BUILD_TYPE=Debug $ARTEXAMPLE_SOURCE
make
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
makehits.fcl
- Run two producers and one analyzer that checks products made by the producers. Also write a file. Use scheduled reco.
readhits.fcl
- Read from the file made in makehits.fcl. Just run the analyzer.
readhits2.fcl
- This is makehits.fcl but done with reco on demand. Does not make the output file.
readhits4.fcl
- 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?
readhits5.fcl
- 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.
History
#1 Updated by Marc Paterno over 9 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.
#2 Updated by Christopher Green over 9 years ago
- Category set to Navigation
- Status changed from Feedback to Assigned
- Assignee set to Christopher Green
- Priority changed from Normal to Low
Existing dropOnInput() mechanism will be tested to determine suitability for use in this arena.
#3 Updated by Walter E Brown about 9 years ago
- Tracker changed from Bug to Meeting
- Assignee deleted (
Christopher Green) - Priority changed from Low to Normal
#4 Updated by Christopher Green over 7 years ago
- Tracker changed from Meeting to Feature
- Due date set to 09/30/2013
- 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
This is a change in behavior.
#5 Updated by Christopher Green almost 7 years ago
- Target version changed from 1.09.00 to 521
#6 Updated by Christopher Green almost 7 years ago
- Status changed from Assigned to Accepted
#7 Updated by Kyle Knoepfel about 3 years ago
- Target version deleted (
521)