Feature #1246: Reco on demand not finding products in the file - art - Fermilab Redmine

Feature #1246

Reco on demand not finding products in the file

Added by Rob Kutschke almost 9 years ago. Updated about 2 years ago.

Status:

Accepted

Priority:

Normal

Assignee:

Category:

Navigation

Target version:

Start date:

04/23/2011

Due date:

09/30/2013

% Done:

Estimated time:

24.00 h

Scope:

Internal

Experiment:

Mu2e

SSI Package:

art

Duration: 892

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 8 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.