Reason for change
The new version contains some fine tuning of specific limits, as well as the new alarms on the normalized rates; the proposed version of the dataMonitoring/AlarmsCfg package is v5r8p8, as opposed to v5r8p4, previously running in L1Proc 1.70.
The detailed description of the changes is in the last section.
Test Procedure
We have processed monitoring products from real on-orbit data (LPA) locally with this version of AlarmsCfg.
Rollback procedure
The package can be rolled back to the previous version by flipping a soft link. Also note that the package is completely independent from any other package running in the pipeline and will not cause a version change of L1Proc.
CCB Jira
Details
v5r8p8
- Added alarms on the normalized rates.
v5r8p7
- Exception added on LEX1 and LEX8 pedestal rms for channel 1160.
- Minor limit change in RPM_Mean_TH1 y_values.
v5r8p6
- Changes in both digi_eor and fastmon_eor
- CondArrCNOTrigger_TH1 : low_high_ratio limits tuned so that max should not fire the alarm
v5r8p5
- Changes in both digi_eor and fastmon_eor
- CondArrCNO_TKROpensWindow_TH1 : low_high_ratio limits tuned so that max should not fire the alarm
Reasons for Change
- Several JIRA issues related to the source monitoring task and release of data to the FSSC (see details below)
- Move to ST v9r9. This will allow ASP to take advantage of precomputed gtdiffrsp columns that will be produced by L1Proc.
- The ASP version is v2r11p1 (One cannot change the page name of a news item in Confluence)
Test Procedure
Tested in dev on data in /ASP/TestSims2. The script that extracts the source monitoring results for shipping to FSSC has been run by hand on prod data and the results have been inspected by hand by Julie and me.
Rollback Procedure
Revert to ASP v2r10p2 and ST v9r7p1. Revert diffsrc_name="Galactic Diffuse" entry in DIFFUSESOURCES db table.
CCB Jira
Details
- ASP-55@jira Use recommended Galactic Diffuse model
- ASP-56@jira Enable release to FSSC of monitored sources other than DRP-designates
- ASP-57@jira Release upper limits for the 23 DRP sources
- ASP-58@jira skip last GRB refinement steps if data extraction returns no events
- ASP v2r11p1
- AspHealPix v0r0p1
- AspLauncher v1r3p6
- AspPolicy v0r6p1
- BayesianBlocks v1*
- switch to using intervals between arrival times instead of Voronoi cells
- asp_pgwave v1r9p1*
- added GALPROP_MODEL variable to xml task definitions to facilitate switchover for recommended Galprop model
- use GtApp to drive gtsrcid
- drpMonitoring v1r7*
- added GALPROP_MODEL variable to xml task definitions to facilitate switchover for recommended Galprop model
- use addNdifrsp function in diffuseResponse.py and sourceAnalysis.py scripts
- grbASP v4r7p5*
- added GALPROP_MODEL variable to xml task definitions to facilitate switchover for recommended Galprop model
- use addNdifrsp function in GRB_refinement and GRB_afterglow tasks
- pyASP v3r5p7*
- added addNdifrsp.py to add NDIFRSP keyword to older FT1 files
- Here are some plots illustrating what will be released under the new policy:
The upper left plot shows the daily fluxes that are currently being released for PKS 2155-304, a DRP source. These are flux measurements for which TS > 25. The upper right plot shows the data that would be released under the new policy: the daily fluxes (as before) and the 90% CL upper limits (inverted triangles). The lower left and right plots show the daily data that would be released (black points only) for the two sources PKS 1502+106 (ASPJ1504+102709) and PKS 1454-355 (ASPJ145759-351535). The red points are the positive detections (TS > 25) that are not part of a flare event that satisfies the DRP flux limit of 2e-6 ph/cm^2/s.
Reason for change
The new version contains some fine tuning of specific limits; the proposed version of the dataMonitoring/AlarmsCfg package is v5r8p4, as opposed to v5r8p2, previously running in L1Proc 1.70.
The detailed description of the changes is in the last section.
Test Procedure
We have processed monitoring products from real on-orbit data (LPA) locally with this version of AlarmsCfg.
Rollback procedure
The package can be rolled back to the previous version by flipping a soft link. Also note that the package is completely independent from any other package running in the pipeline and will not cause a version change of L1Proc.
CCB Jira
Details
v5r8p4
- Changes in both digi_eor and fastmon_eor
- CondArrTKR_CalLoOpensWindow_TH1 : low_high_ratio limits tuned so that max should not fire the alarm
- Relevant jira(s): GDQMQ-291
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
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
Reason for change
The new version contains some fine tuning of specific limits; the proposed version of the dataMonitoring/AlarmsCfg package is v5r8p2, as opposed to v5r8p0, previously running in L1Proc 1.69.
The detailed description of the changes is in the last section.
Test Procedure
We have processed monitoring products from real on-orbit data (LPA) locally with this version of AlarmsCfg.
Rollback procedure
The package can be rolled back to the previous version by flipping a soft link. Also note that the package is completely independent from any other package running in the pipeline and will not cause a version change of L1Proc.
CCB Jira
Details
v5r8p2
- CalX_NHit_TH1_Tower limits relaxed a bit more.
v5r8p1
All of the following changes apply to fastmon and digi eor:
- CondArrCalLo_CNOOpensWindow_TH1 : min entries = 50.
- CondArrCalHi_CNOOpensWindow_TH1 : min entries = 25.
- CondArrTKR_CNOOpensWindow_TH1 : lower limits set to 0.
- CondArrROITrigger_TH1 : lower warn limit on low_high_ratio moved from 100 to 90.
- CalX_NHit_TH1_Tower: limits relaxed a bit.
- Relevant jira(s): GDQMQ-291