Feature #8270

Facility to document creation of branch names and branch IDs

Added by Kyle Knoepfel almost 6 years ago. Updated over 5 years ago.

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


Estimated time:
1.00 h
Spent time:
SSI Package:


Whenever RootInput files are read in to an art job, a check is made to ensure consistency in the BranchIDLists between files. The BranchID values contained on these lists are checksums that have been generated from the branch name. Although the branch name is not generally stored in the file, it is stored in the ProductRegistry for products that have been kept for that process. Unfortunately this is not sufficient for debugging branch mismatch errors. Users occasionally see errors that a branch mismatch exists between input files, but then receive no further information. The BranchID values are stored for the input files, but unless the mismatch corresponds to a product in the ProductRegistry (i.e. is a kept product), there is no way to retrieve the name of the branch(es) that caused the branch mismatch.

The art team should add debugging information so that it is easier to resolve this kind of error. I envisage two options:

  • Simply adding mf::LogDebug (or equivalent) calls whenever the checksum is made, so that the (BranchID, branch name) pair is printed out, or
  • Add a dedicated ProductTracker service that tracks where each product is created, and possibly consumed (to anticipate a future development of art).

Associated revisions

Revision b365da3d (diff)
Added by Kyle Knoepfel almost 6 years ago

Implement issue #8270


#1 Updated by Christopher Green almost 6 years ago

  • Category set to Metadata
  • Assignee set to Kyle Knoepfel
  • Target version set to 1.14.00
  • Estimated time set to 1.00 h
  • SSI Package art added
  • SSI Package deleted ()

We can easily implement (1). (2) is reasonable, but is best tackled when we implement a planned major overhaul of the metadata system.

#2 Updated by Kyle Knoepfel almost 6 years ago

  • Status changed from New to Assigned

#3 Updated by Kyle Knoepfel almost 6 years ago

  • Status changed from Assigned to Resolved
  • % Done changed from 0 to 100

Whenever there is a branch mismatch, a printout now exists that looks like:

  Cannot merge file '<some_rootfile>.root' due to a branch mismatch.

   Previous File    File to merge
   2556661413       2556661413   
   701045456        3413590908   
   3413590908       3893403090   
   3893403090       741045478    
   741045478        4113287237   
   4113287237       3717081787   
   3717081787       3129636888   
   3129636888       2464441433   
   2464441433       2344735897   
   2344735897       3825369613   
   3825369613       680204693    
   680204693        71657639     
   71657639         393939105    
   393939105        3944962766   
   3944962766       360663258    
   360663258        1023633757   
   1023633757       1832547360   
   1832547360       653380120    
   653380120        808754512    
   808754512        1079679939   
   1079679939       481487918    
   481487918        333880152    
   333880152        2511341726   
   2511341726       765148699    
   765148699        378294740    
   378294740        3611458318   

  The BranchIDs above correspond to products
  that were created whenever the current input files
  were produced.  The lists above must be identical.
  To determine which products these BranchIDs correspond to,
  rerun the process that produced the input files,
  enabling full debug output for the message service.
  Then 'grep' the log file for messages with 'BranchID'

  Contact the framework group for assistance.

Whenever a user then enables debug printout on the process, each registered product emits a message like:

%MSG-d BranchID:  TriggerResultInserter:TriggerResults@Construction  15-Apr-2015 15:16:20 CDT ModuleConstruction
Product created with branch id: [1838029815] from branch name: "art::TriggerResults_TriggerResults__MemoryTracker." 

Where not only is the mapping given between the branch id and the branch name, but the location of the produces<...>() call is also given: in the constructor of the TriggerResultInserter module, with the module label TriggerResults.

Implemented with b365da3dab0af967a5a7b4c44e4118d3251341a2.

#4 Updated by Kyle Knoepfel over 5 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF