Bug #18996

Product aggregation logic does not correctly act on full-run range products

Added by Gianluca Petrillo about 3 years ago. Updated about 3 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Spent time:
SSI Package:


In the analysis of issue #18943, there was indication that aggregation is attempted on run products covering the full run.
This logic might be not ideal, and some discussion might be needed to determine the preferred behaviour.

Kyle Knoepfel can expand on the topic, as he was the principal investigator of the issue.

Related issues

Related to LArSoft - Bug #18943: Problem with sumdata::RunData aggregationClosed02/09/2018


#1 Updated by Kyle Knoepfel about 3 years ago

  • Status changed from New to Assigned
  • Assignee set to Kyle Knoepfel

#2 Updated by Kyle Knoepfel about 3 years ago

  • Related to Bug #18943: Problem with sumdata::RunData aggregation added

#3 Updated by Kyle Knoepfel about 3 years ago

  • Category set to Metadata
  • Status changed from Assigned to Resolved
  • % Done changed from 0 to 100
  • SSI Package art added

The fix has been implemented with commits:

Along with these changes came a few breaking changes.

File-format version change

There is a file-format version change (11 to 12) because full-run products persisted to disk now have a different representation than in past file-format versions. This allows us to disambiguate between products that represent a full run and those that correspond to no events. The consequence to the user is that all full-run products persisted to files with file-format version 11 and older will be interpreted as corresponding to no events. This means:

  • An aggregate function for reading each already-persisted full-run product is required.
  • The range-of-validity for one of these products will correspond to no events. This can make the interpretation of the product (for the user) ambiguous. However, assuming the user implements a sensible aggregation function for a full-run product (e.g. checking for equality and throwing if the values are different), this should not be an impediment for using these products.

Semantics of art::overlapping_ranges

In the past, the bool art::overlapping_ranges(RangeSet const& a, RangeSet const& b) free function returned false if a and b corresponded to the same ranges. With the next minor release of art, calling overlapping_ranges will return true if art::same_ranges(a, b) also returns true.

#4 Updated by Kyle Knoepfel about 3 years ago

  • Target version set to 2.11.00

#5 Updated by Kyle Knoepfel about 3 years ago

  • Tracker changed from Support to Bug
  • Description updated (diff)
  • Status changed from Resolved to Closed
  • Experiment LArSoft added
  • Experiment deleted (-)

#6 Updated by Kyle Knoepfel about 3 years ago

  • Project changed from art to canvas
  • Category deleted (Metadata)

Also available in: Atom PDF