Reason for change
Bug fix for GCR crash in recon in run 256381943. This requires a new GlastRelease. We have also fixed the LD_LIBRARY_PATH problem that meant we did not properly apply the leap second correction. For consistency reasons, we now have the same version of the astro package in both Glast Release and Science Tools. And we have a few bug fixes and updates for the monitoring.
Test Procedure
We have processed data runs 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 v1r71:
- Handle leap seconds properly, JIRA LONE-123.
- Clean up LD_LIBRARY_ and CMT PATHs. LONE-123@JIRA
- Put some info in dontCleanUp locks. LONE-127@JIRA
- Combine setSuccessful and setCrashed into a single script.
- checkRun fails if dontcleanup is present. LONE-133@JIRA
- Store deliveries from Halfpipe in a more official place. LONE-119@JIRA
- ft2Fake files cover only their chunk. LONE-138@JIRA
- Read data from xrootd when making magic7 file. LONE-129@JIRA
- mergeStuff fails before reading input data if it needs pyROOT and can't import it. LONE-134@JIRA
- When making ft1 and ls1, get start,stop times by rounding first,last event times down,up to .1s DATASERV-151@JIRA
GlastRelease v15r47p5:
- There are two changes in this GR wrt the version in use in L1, GR v15r47p1. We have a new version of GCRCalib: "Fix two bugs in the way m_initDir is initialized, and the case of no track in TDS". This fixes the crash we had in run 256381943. Fred Piron also verified that this new version did not change the 2400 events before the crash. We also have updated to the same version of astro that we use in Science Tools. We reprocessed a run and Andrea verified that there were no unexpected changes in the FT2 file.
- No changes in the system tests wrt GR v15r47p1.
dataMonitoring/DigiReconCalMeritCfg: v1r3p4
- Add the quantity Rate_FastMon_AnyThingButTEM to the FastMon trending configuration file.
- Changes to address JIRA GDQMQ-249
svac/Monitor: v1r2p35
- Proper initialization of vectors. This might be the cause of the problem described in JIRA GDQMQ-305.
svac/TestReport: v8r0
- Added datagram ID to the error message, where appropriate
- Fixed a bug in the computation of the size of datagram gaps
Complete set of tags for L1Proc 1.71
Code Versions
GlastRelease (sim/recon): v15r47p5*
ScienceTools (Level 2) : v9r8p2
Science Ops (task defs, scripts):
Level 1 pipeline code and applications running in L1:
svac/L1Pipeline: v1r71*
calibTkrUtil v2r7p3
calibGenTKR v4r5
dataMonitoring/AlarmsCfg: v5r9p4
dataMonitoring/FastMonCfg: v1r6p1
dataMonitoring/DigiReconCalMeritCfg: v1r3p4*
dataMonitoring/Common: v5r7p0
dataMonitoring/FastMon: v4r5p1
datMonitoring/IGRF: v1r0p1
svac/Monitor: v1r2p35*
svac/EngineeringModelRoot: v4r3
svac/TestReport: v8r0*
users/richard/pipelineDatasets: v0r6
ft2Util: v1r2p23
evtClassDefs v0r6
GPLtools: fileOps1
- Powered by Atlassian Confluence 2.10.1, the Enterprise Wiki.
- Printed by Atlassian Confluence 2.10.1, the Enterprise Wiki.
- Bug/feature request \u2013
- Atlassian news \u2013
- Contact administrators