Reason for change
The previous L1Proc introduced a new type of quantity that needed to be propagated to the Tree mergeing. It was not (oversight). While the testing was done with multi-chunk runs they were not not adjacent and did not trigger this bug. Testing procedures have now been changed.
Test Procedure
We have processed both MC and real data on the DEV server with this version of L1Proc.
Rollback procedure
We can roll back to the previous version of L1Proc.
CCB Jira
Details
svac/Monitor: v1r1p12
- Modfied treemerge.cxx so that the merged quantity is not the largest value, but the last value. This is done in case the DataTransferId has decreasing numbers.
- Added merging of quantity outputnumber (prefix Number_) which is an UInt_t. The merging consists in using the largest value. This is a temporal solution to deal with quantity Number_LastDataTransferId. The proper way to go is to define thsi quantiy as ValChange update the data base to deal with ValChange quantities.
Complete set of tags for L1Proc 1.51
Code Versions
GlastRelease (sim/recon) v14r11
ScienceTools (Level 2) : v9r5p4
Science Ops (task defs, scripts):
Level 1 pipeline code and applications running in L1:
svac/L1Pipeline: v1r51*
dataMonitoring/AlarmsCfg: v1r1p0
dataMonitoring/FastMonCfg: v1r1p11
dataMonitoring/DigiReconCalMeritCfg: v1r1p16
dataMonitoring/Common: v3r1p5
dataMonitoring/FastMon: v3r1p4
datMonitoring/IGRF: v1r0p1
svac/Monitor: v1r1p12*
svac/EngineeringModelRoot: v3r14p3
svac/TestReport: v6r8
calibTkrUtil v2r2p1
users/richard/pipelineDatasets: v0r4
ft2Util: v1r2p15
evtClassDefs v0r3
GPLtools: v1r10