Reason for change
File versioning in the L1 pipeline: The reason for this is that a run will usually be processed piecemeal (run cut by a downlink/data transfer, missing data showing up, etc). While we only process a contiguous chunk of data once, we always merge up everything every time we process a piece of a run. It's the latest version of the merged file that will be the most complete and which will be of (most) interest. The infrastructure (Data catalog etc) needs to take this into account.
Test Procedure
We have processed both MC and real data on the DEV/TEST server with this version of L1Proc.
Rollback procedure
Rolling back to the previous version of L1Proc must be coordinated with similar rollback of infrastructure code.
CCB Jira
Details
evtClassDefs v0r4
- Update to event classifications for P6_v1 irfs.
Complete set of tags for L1Proc 1.52
Code Versions
GlastRelease (sim/recon) v15r2
ScienceTools (Level 2) : v9r5p4
Science Ops (task defs, scripts):
Level 1 pipeline code and applications running in L1:
svac/L1Pipeline: v1r52*
dataMonitoring/AlarmsCfg: v1r1p0
dataMonitoring/FastMonCfg: v1r1p11
dataMonitoring/DigiReconCalMeritCfg: v1r1p16
dataMonitoring/Common: v3r1p5
dataMonitoring/FastMon: v3r1p4
datMonitoring/IGRF: v1r0p1
svac/Monitor: v1r1p13
svac/EngineeringModelRoot: v3r14p4
svac/TestReport: v6r8
calibTkrUtil v2r2p2
users/richard/pipelineDatasets: v0r4
ft2Util: v1r2p15
evtClassDefs v0r4*
GPLtools: v1r10