Reason for change
We have a new GR, v15r2, which includes the Pass7 changes and also updates to the GCR algorithm.
The previous L1Proc introduced a new type of monitoring quantity that needed to be propagated to the Tree mergeingmerging. It was not (oversight). While the testing was done with multi-chunk runs they were not not adjacent and did not trigger this bug. The script is intelligent enough to only do a straight copy in that case. Testing procedures will be changed.
We also have a fix for a memory leak in merging Hiro's TKR monitoring histograms.
And finally, we have a new GR, v15r2, which includes the Pass7 changes and also updates to the GCR algorithm.
Test Procedure
We have processed both MC and real data on the DEV server with this version of L1Proc.
...
GlastRelease v15r2:
- The GR v15 series is identical to GR v14 except for the Pass 7 stuff.
- Systemtestsfor GR v15r2wrt GR v14r11 show no differences.
- RM diffwith respect to the previous production release, GR v13r11p9. I will not detail the changes here as there are understandably too manyv14r11.
svac/Monitor: v1r1p13
- 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 temporary solution to deal with quantity Number_LastDataTransferId. The proper way to go is to define this quantiy as ValChange and update the data base to deal with ValChange quantities. And that ain't happening anytime soon 
...