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 10 years ago. Updated over 3 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 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.