Reason for change
Leap seconds! To be able to correctly handle the leap second at the end of the year we have to a) make a small change to the monitoring code in two places to fix a histogram and b) start using a more recent Science Tools release. This latter is for an entry in the FT1 header which apparently is not used by anyone. But you never know ..... No code in Glast Release depend on any leap second.
We also have a retuning of the normalized ("expected") rates vs the geomagnetic parameter PtMcIlwainL and some minor changes to the monitoring code.
Test Procedure
We have processed data runs (LPA and LCI) in the DEV pipeline with this version of L1Proc.
Rollback procedure
We can switch back to the previous version of L1Proc.
CCB Jira
Details
L1Pipeline v1r70:
- Handle leap seconds since 2004.
- Automatically set run quality to good if it is unset.
- Fix regexps used for parsing bqueues output.
- Put LCI data in LCI folder.
Science Tools: v9r8p2
- Correctly handle leap second in FT1 header, JIRA LONE-120.
dataMonitoring/DigiReconCalMeritCfg: v1r3p3
- New file to normalize rates. This addresses jira GDQMQ-300. The normalization factors were obtained with data from 56 days: 2008-09-20 00:00:00: MET 243561600 to 2008-11-16 00:00:00: MET 248486400. The data related to the Earth Albedo observation was removed.
- Changes to address jira GDQMQ-277
dataMonitoring/Common: v5r7p0
- Bug fix in the alarm handler (the output status was not correctly overridden under some circumstances). Relevant jira(s): GDQMQ-297
- Output status for alg__low_high_ratio set to ERROR when the pivot point is not defined.
- Output status for alg__reference_histogram set to ERROR in case any problem is encountered while running the algorithm.
- pAlarmBaseAlgorithm modified in such a way the output status for all the alarms is set to ERROR in case the root object is invalid. Relevant jira(s): GDQMQ-293
- Doxygen documentation added to alg__low_high_ratio.py. Relevant jira(s): GDQMQ-294
dataMonitoring/FastMon: v4r5p1
- pCustomPlotter.py : The input tree is now cloned before being used, and in particular copy with cuts to create the plots. For some reason I do not understand, this fixes the crash seen with ROOT version greater than v5.18.00. The trick work with v5.20 and is backward compatible with 5.18. Relevant jira(s): GDQMQ-266
svac/Monitor: v1r2p34
- Change to address jira GDQMQ-295.
- Change to address jira GDQMQ-275
svac/TestReport: v7r7
- Taking into account leap second from Dec 31st, 2008 (GDQMQ-296)
dataMonitoring/AlarmsCfg: v5r8p3
- Changes in both digi_eor and fastmon_eor
- CondArrCalHi_CNOOpensWindow_TH1 : remove low_high_ratio, extend mean and rms, require only 10 events per histogram
- CondArrTKR_CNOOpensWindow_TH1 : extend x_average limit slightly
- CondArrROI_CNOOpensWindow_TH1 : extend x_average limit slightly
- Relevant jira(s): GDQMQ-291
Complete set of tags for L1Proc 1.70
Code Versions
GlastRelease (sim/recon): v15r47p1
ScienceTools (Level 2) : v9r8p2*
Science Ops (task defs, scripts):
Level 1 pipeline code and applications running in L1:
svac/L1Pipeline: v1r70*
calibTkrUtil v2r7p3
calibGenTKR v4r5
dataMonitoring/AlarmsCfg: v5r8p3*
dataMonitoring/FastMonCfg: v1r6p1
dataMonitoring/DigiReconCalMeritCfg: v1r3p3*
dataMonitoring/Common: v5r7p0*
dataMonitoring/FastMon: v4r5p1*
datMonitoring/IGRF: v1r0p1
svac/Monitor: v1r2p34*
svac/EngineeringModelRoot: v4r3
svac/TestReport: v7r7*
users/richard/pipelineDatasets: v0r6
ft2Util: v1r2p23
evtClassDefs v0r6
GPLtools: v1r13p1