Problem with reading filter file
Our student Ivan Lepetic had a problem reading filtered file. He ran a filter to only select one event and save it to an art root file. However, he failed to run any art job using the file as an input. I have attached the root file and to reproduce the problem, one can do:
art -c eventdump.fcl filtered_OList_newfcl.root
It will give the error:
%MSG-s ArtException: PostProcessPath end_path 11-May-2017 16:02:55 CDT PostProcessEvent cet::exception caught in art ---- LogicError BEGIN Attempt to merge event ranges that both contain one or more of the same events SubRun: 1 Event range: [1,2001) vs. SubRun: 1 Event range: [465,1732) ---- LogicError END %MSG Art has completed and will exit with status 10.
Thanks for any help on this.
p.s. It would be great if you could add Ivan Lepetic to this ticket. Thanks!
#1 Updated by Kyle Knoepfel over 3 years ago
- Tracker changed from Bug to Support
- Status changed from New to Assigned
- Assignee set to Kyle Knoepfel
It looks like the file is a result of a large concatenation job. Executing
file_info_dumper --range-of-validity filtered_OList_newfcl.root
============================== File: filtered_OList_newfcl.root ... Run: 784 SubRun: 1 Event range: [1,44304) Run: 785 SubRun: 1 Event range: [1,33696) Run: 787 SubRun: 1 Event range: [1,35767) ---- LogicError BEGIN Attempt to merge event ranges that both contain one or more of the same events SubRun: 1 Event range: [1,2001) vs. SubRun: 1 Event range: [465,1732) ---- LogicError END
The output here corresponds to what events were processed in making this file. Unfortunately, the error message doesn't give the run number where the problem arose (that's been fixed for
art 2.07, soon to be released), but using
gdb, I find that the exception is thrown for run
This type of error can arise if the same events were processed twice at some point during the processing that led to the
filter_OList_newfcl.root output file. More specifically, this is telling you that events 465 through 1731 (inclusive) of
SubRun 1 were already accounted for in a different set of input files.
In order to diagnose further, you should run the
file_info_dumper command above on the input files that contain
Run 788. This will tell us which input file(s) are the culprit. I suspect you will get a printout in one file that looks like:
Run 788: SubRun: 1 Event range: [1,2001)and a print out in another file that looks like:
Run 788: SubRun: 1 Event range: [465,1732)Once you find those input files, you can dump out the event lists (using
file_info_dumper --event-list <file>) and I suspect we'll find that the same events are in both files.
#2 Updated by Ivan Lepetic over 3 years ago
When I try using the
file_info_dumper --range-of-validity command on input (raw data) files, I get the following message:
File: R788_E1-E2000.root Warning in <TClass::Init>: no dictionary for class art::Transient<art::ProductRegistry::Transients> is available ---- FileReadError BEGIN InfoDumperInputFile::print_range_sets Range-set information is not available for art/ROOT files with a format version of "ART_2011a: 5". ---- FileReadError END
If I try instead to list all events in that file, using
file_info_dumper --event-list, I get:
File: R788_E1-E2000.root Warning in <TClass::Init>: no dictionary for class art::Transient<art::ProductRegistry::Transients> is available
and no events are listed. Is there a way around this?
#3 Updated by Kyle Knoepfel over 3 years ago
Okay, so you're reading a file for which the range-of-validity is not supported. In that case, please do the following:
touch empty.fcl art -c empty.fcl --trace -s R788_E1-E2000.root > events.log 2>&1
And then do a grep of the output for:
grep "processing event:" events.log
This will give you the list of events that that file contained.