Reason for change
Test procedure
The change is trivial and there is a bit of test code in the python module exercising the relevant cases.
Rollback procedure
The package can be rolled back to the previous version.
CCB JIRA
Details (release notes for IGRF-02-01-01)
- IGRF now checking whether the IGNORE_IGRF_BOUNDARY environmental variable is defined before raising an exception if the require model date is outside the model boundaries (this is similar to what the IGRF implementation in astro is doing).
* Relevant Jira(s): GDQMQ-369
Reason for change
Test Procedure
We have read through the new tag of the package one of the offending M7 files
/nfs/farm/g/glast/u28/stage/141201003/magic7_141201003.txt
and verified that the output is now correct.
Rollback procedure
The package can be rolled back to the previous version.
CCB Jira
Details (release notes for FastMon-05-03-03)
Bug fix in the way we calculate the (floating point year-equivalent) of the date and time in the M7 file to be passed to the IGRF package to initialize the Geomagnetic field model. Essentially the patch changes the old implementation
yearfloat = year + month/12.
to
yearfloat = year + (month - 1)/12. + (day - 1)/365.
Relevant thread(s):
https://www-glast.stanford.edu/protected/mail/opsprob/8065.htmlReason for change
We request to put AlarmsCfg-06-04-01 in production. The new tag implements a few tweaks to the alarm limits, as detailed in the last section of this page.
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 (release notes for AlarmsCfg-06-04-01)
A few tweaks in the alarms on the GPS 20 MHz deviation. Essenatially for digi_eor_alarms.xml, digi_trend_alarms.xml and fastmon_eor_alarms.xm the basic diff is
< <warning_limits min="-196.0" max="-165.0"/>
< <error_limits min="-200.0" max="-150.0"/>
---
> <warning_limits min="-210.0" max="-180.0"/>
> <error_limits min="-230.0" max="-160.0"/>
Relevant thread(s):
A lot of emails circulated on the datamon list over the last few weeks, see, e.g.,
https://www-glast.stanford.edu/protected/mail/datamon/13535.html
Reason for change
We request to put AlarmsCfg-06-04-00 in production. The new tag implements a few tweaks to the alarm limits, as detailed in the last section of this page.
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 (release notes for AlarmsCfg-06-04-00)
- merit_trend OutF_NormRateMeritTriggerEngine (engine 7): raise the upper warning limit from 1.15 to 1.25
- merit_trendOutF_NormRateEvtsBeforeCuts: raise the upper warning limit from 1.15 to 1.20
- merit_trendOutF_NormRateEvtsBeforeCutsWithFswGAMMAFilter: raise the upper warning limit from 1.15 to 1.20
- Minimum number of entries for fastmon_eor CalLogEndRangeHitCounter_Range0_TH2_Tower_* changed from 1000000 to 750000.
- acdpeds_eor upper warning limit for AcdPedPedMeanDeviation_PMTB_TH1 (y_values) changed from 8 to 10.
- Added exceptions for calpeds_eor for channels 824: CalXAdcPedPedRMSDifference_HEX1_TH1, CalXAdcPedPedMeanDifference_HEX1_TH1 and CalXAdcPedPedMeanDifference_HEX8_TH1
- Added exceptions for calpeds_eor for channels 3060: CalXAdcPedPedMeanDifference_LEX8_TH1, CalXAdcPedPedRMSDifference_LEX8_TH1
Relevant thread(s):
https://www-glast.stanford.edu/protected/mail/datamon/12916.html
https://www-glast.stanford.edu/protected/mail/datamon/12589.html
Reasons for Change
- Update to use ScienceTools-09-33-00 and rhel6-64 builds.
Test Procedure
Tested in dev on data in /ASP/TestSims2 and on prod tables for Monitored Source List FITS file generation.
Rollback Procedure
Revert to ASP-06-02-00 (ScienceTools-09-32-05)
CCB Jira
Details
Reason for change
This is the version needed for P203 The switchover is planned for Tuesday, June 3rd.
Test Procedure
We have processed several LPA and LCI runs in the DEV pipeline with this version of L1Proc.
Rollback procedure
We can easily switch back to the previous version of L1Proc before the FSSC switches over to the new photon database (we probably have a few hours to rollback, if needed).
CCB Jira
Details
L1Pipeline: L1Pipeline-04-08-00
- Updated ScienceTools and diffuse model.
- FastMon-05-03-02 (with a fix for GDQMQ-368).
- Rename 1-second FT2s.
- Export 1-second FT2s in L1Proc and flagFT2.
- Fix permissions problem with cleanupDl.
- Update GPLtools to use new netlogging destinations.
ScienceTools: ScienceTools-09-33-00
dataMonitoring/FastMon: FastMon-05-03-02
- bug fix on pM7Parser::getSCPosition as per GDQMQ-368 (check if the M7 value returned is within 60 s of the requested space craft time).
Complete set of tags for L1Proc 4.8
GlastRelease: GlastRelease-17-35-24-lp61
ScienceTools: ScienceTools-09-33-00
svac/L1Pipeline: L1Pipeline-04-08-00
calibGenTKR: calibGenTKR-04-08-01
calibTkrUtil: calibTkrUtil-02-09-06-gr02
fitsGen: fitsGen-06-06-05
dataMonitoring/AlarmsCfg: AlarmsCfg-06-03-03
dataMonitoring/Common: Common-06-12-00
dataMonitoring/DigiReconCalMeritCfg: DigiReconCalMeritCfg-01-20-04
dataMonitoring/FastMon: FastMon-05-03-02
dataMonitoring/FastMonCfg: FastMonCfg-02-02-01
datMonitoring/IGRF: IGRF-02-01-00
svac/Monitor: Monitor-02-01-04
svac/EngineeringModelRoot: EngineeringModelRoot-05-00-00
svac/TestReport: TestReport-12-01-00
svac/findGaps: findGaps-02-02-00
users/richard/pipelineDatasets: pipelineDatasets-01-00-00
ft2Util: ft2Util-02-02-00
evtClassDefs: evtClassDefs-00-19-05
GPLtools: GPLtools-02-00-00-wf02
ROOT: ROOT v5.26.00a-gl6
Reason for change
We are now using the absolute value of rocking angle in DQM trending, to mitigate persistent normalization issues.
There is also a minor tweak to the alarm limits (we are deploying AlarmsCfg-06-03-03, see the release.notes) to cope with a known minor issue with an ACD tile.
Test Procedure
We have processed an LPA run in the DEV pipeline with this version of L1Proc. The "before" and "after" plots below show that the correction is effective.
| Normalized Rate of Source Events, L1Proc 4.5 (before the rocking angle correction) | Normalized Rate of Source Events, L1Proc 4.5 (after the rocking angle correction) |
 |  |
Rollback procedure
We can easily switch back to the previous version of L1Proc.
CCB Jira
Complete set of tags for L1Proc 4.6
GlastRelease: GlastRelease-17-35-24-lp61
ScienceTools: ScienceTools-09-32-05
svac/L1Pipeline: L1Pipeline-04-06-00
calibGenTKR: calibGenTKR-04-08-01
calibTkrUtil: calibTkrUtil-02-09-06-gr02
fitsGen: fitsGen-06-06-05
dataMonitoring/AlarmsCfg: AlarmsCfg-06-03-03
dataMonitoring/Common: Common-06-12-00
dataMonitoring/DigiReconCalMeritCfg: DigiReconCalMeritCfg-01-20-04
dataMonitoring/FastMon: FastMon-05-03-00
dataMonitoring/FastMonCfg: FastMonCfg-02-02-01
datMonitoring/IGRF: IGRF-02-01-00
svac/Monitor: Monitor-02-01-04
svac/EngineeringModelRoot: EngineeringModelRoot-05-00-00
svac/TestReport: TestReport-12-01-00
svac/findGaps: findGaps-02-02-00
users/richard/pipelineDatasets: pipelineDatasets-01-00-00
ft2Util: ft2Util-02-02-00
evtClassDefs: evtClassDefs-00-19-05
GPLtools: GPLtools-02-00-00-wf02
ROOT: ROOT v5.26.00a-gl6
Reason for change
We request to put AlarmsCfg-06-03-02 in production. This implements the third round of tweaks to cope with the new rocking profile.
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 (release notes for AlarmsCfg-06-03-02)
- Upper limits on the digi_eor Tick20MHzDeviation_TH1 (x_average) moved from -176/-168 to -165/-150.
- Upper limits on the fastmon_eor Tick20MHzDeviation_TH1 (x_average) moved from -176/-168 to -165/-150.
- Upper limits on the digi_trend Tick20MHzDeviation_TH1 moved from -176/-168 to -165/-150.
- Upper limits on the digi_trend OutF_Ratio_EvtSize_CompressedEvtSize changed from 5.75/6 to 5.85/6.25.
Relevant thread(s):
- https://www-glast.stanford.edu/protected/mail/datamon/11758.html
Here is the time history of the deviation (in clock ticks) of the GPS internal clock wrt the 1 PPS. I haven't looked at the temperature profile in the same time period, but we know that the the crystal is a good thermometer and I will take for granted that the trend is entirely due to a temperature variation (at 0.5 ppm/degree 30 clock ticks at 20 MHz imply something like a change of 3 degrees in temperature).
And here is a plot from Eric Siskind, confirming that the clock drift is indeed due to temperature changes.
For reference, here is an excerpt from a related e-mail exchange.
Do we expect the temperature to continue to trend upwards (as it has been doing since December 20th)? At what point does overheating the battery become a concern?
-Alex
Hi Alex:
The answer to the first question is that it depends on whether the current GASU temperature rise is a result of the solar beta angle change (which goes through about 8 complete cycles per year) or the angle between the Sun and the IP target (which goes through one complete cycle per year). We’re very close to a beta angle peak (which is one of the two largest negative excursions in the current year; both centered about the winter solstice). If the current temperature rise is the result of the beta angle, then we should see the GASU temperature begin to fall about a week from now. If it’s the annual cycle that is causing the temperature rise, then you really have to understand heat flow through the LAT in order to predict when that cycle will reach a maximum. If you adopt a really simple model and neglect the heat that is flowing through the grid because of sunlight hitting the instrument at more positive Z values, then you might conclude that the maximum temperature will occur near the time of the year when the Sun is right along the +X axis during the IP portion of each orbit. My understanding of the geometry is that those peaks will occur in March and September, but that understanding of the geometry is not exactly ideal.
As far as the battery goes, there we know that the problem will be worst when the Sun is near the –Z axis. As Julie has just said, the battery is cold and happy right now (because the Sun is in the +Z hemisphere), but it definitely has become quite a bit warmer over the last few weeks. Right now, it’s only about as cold as it was when we first started 50 degree sky survey, or certainly within a degree of that. Again, I’m not certain whether the rise over the last few weeks is the result of the beta cycle, but I’m suspicious (and hopeful!) that this indeed so. If it is so, then again we should start seeing the battery temperature drop within another week or so. In fact, I certainly didn’t expect to see the battery temperature rise from the annual cycle until we get to the vernal equinox, and we certainly have seen the effects of the beta cycle in the past when we were observing in almost pure 50 degree sky survey mode. If we hadn’t changed the observing strategy, then I would expect that the battery would be 5-6 degrees warmer than it currently is.
ejs
Reason for change
We request to put AlarmsCfg-06-03-01 in production. This implements the second rounds of tweaks to cope with the new rocking profile.
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 (release notes for AlarmsCfg-06-03-01)
- Upper limits on merit_trend Rate_TransientEvts changed from 110/15 to 150/200.
- Upper yellow limit on merit_trend Rate_SourceEvts changed from 50 to 60.
- Lower limits on fastmon_trend Mean_FastMon_CalTowerCount changed from 2.0/2.5 to 1.5/2.0.
- Upper yellow limit on digi_trend Rate_FswFilters_GAMMA changed from 1000 to 1200.
- Lower yellow limit on digi_trend OutF_Normalized_AcdHit_AcdTile changed from 0.04 to 0.03 for tiles 64--89.
Relevant thread(s):
- https://www-glast.stanford.edu/protected/mail/datamon/11711.html
And a few plots to justify the changes (below two sample time periods before and after the change of the observation strategy are compared). I apologize the vertical scales are different.
| Plot (before) | Plot (after) | Comment |
|---|---|---|
 |  | - |
 |  |
Reason for change
Allow running on RHEL6 batch hosts.
Test Procedure
We have processed an LPA run in the DEV pipeline with this version of L1Proc.
Rollback procedure
We can easily switch back to the previous version of L1Proc.
CCB Jira
Complete set of tags for L1Proc 4.5
GlastRelease: GlastRelease-17-35-24-lp61
ScienceTools: ScienceTools-09-32-05
svac/L1Pipeline: L1Pipeline-04-05-00
calibGenTKR: calibGenTKR-04-08-01
calibTkrUtil: calibTkrUtil-02-09-06-gr02
fitsGen: fitsGen-06-06-05
dataMonitoring/AlarmsCfg: AlarmsCfg-06-02-00
dataMonitoring/Common: Common-06-12-00
dataMonitoring/DigiReconCalMeritCfg: DigiReconCalMeritCfg-01-20-02
dataMonitoring/FastMon: FastMon-05-03-00
dataMonitoring/FastMonCfg: FastMonCfg-02-02-01
datMonitoring/IGRF: IGRF-02-01-00
svac/Monitor: Monitor-02-01-04
svac/EngineeringModelRoot: EngineeringModelRoot-05-00-00
svac/TestReport: TestReport-12-01-00
svac/findGaps: findGaps-02-02-00
users/richard/pipelineDatasets: pipelineDatasets-01-00-00
ft2Util: ft2Util-02-02-00
evtClassDefs: evtClassDefs-00-19-05
GPLtools: GPLtools-02-00-00-wf02
ROOT: ROOT v5.26.00a-gl6
Reason for change
We request to put AlarmsCfg-06-02-00 in production. This implements the first rounds of tweaks to cope with the new rocking profile.
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 (release notes for AlarmsCfg-06-02-00
- Upper limits on calpeds_eor CalXAdcPedRMS_LEX1/8_TH1 (algorithm y_values) raised per request by Eric Grove (his original slides are attached).
- Upper warning limit on merit_trend Rate_TransientEvts raised (75 -> 110).
- Upper warning limit on digi_trend OutF_Ratio_EvtSize_CompressedEvtSize raised (5.5 -> 5.75).
- Lower warning limit on digi_trend OutF_Normalized_AcdHit_AcdTile lowered (0.03 -> 0.025) for tiles 0-15, 16-31, 32-47, 48-63.
And a few plots to justify the changes (below two sample time periods before and after the change of the observation strategy are compared). I apologize the vertical scales are different.
| Plot (before) | Plot (after) | Comment |
|---|---|---|
 |  | Proposed change: upper yellow limit 75 -> 110 |
 |  | Proposed change: upper yellow limit 5.5 -> 5.75 I have no idea what the single outlier is. We should probably take a look. |
| I haven't been able to grab this one. |  | Proposed change: lower yellow limit 0.03 -> 0.025 |
Reason for change
We require to deploy this new version (Common-06-12-00) of the dataMonitoring/Common package in order to fix an unintended mis-behavior of the code generating the solar flare plots and suggesting the Bad Time Intervals (essentially no integrated time loss was calculated for the candidate BTIs from the normalized ACD tile count—as opposed to the normalized rate in tile 63). The new tags generates integrated time losses based on the latter quantity when the former is below threshold.
The relevant emeil thread is at https://www-glast.stanford.edu/protected/mail/datamon/11220.html
Test Procedure
We have processed monitoring products from real on-orbit data (LPA) locally with this version of AlarmsCfg.
Upgrade Procedure
The Commons package doesn't depend on any other package in L1Proc and isn't cross-compiled against any other package in L1Proc, so in principle it can be updated without installing a new L1Proc. Getting a full L1Proc built, installed and tested is a process that takes several days, and this time we would like to try and upgrade this package only. The xml and L1 builds will not be updated. This L1Proc will be tagged as L1Proc-04-04-01, which technically means it will be a patch of the existing release (L1Proc-04-04-00).
This upgrade procedure has been tested in DEV. Everything went fine.
Rollback procedure
The package can be rolled back to the previous version by flipping a soft link in the config.py file. As just described, the package is completely independent from any other package running in the pipeline and backing out of this change does not cause any inconvenience.
CCB Jira
Reason for change
We request to put AlarmsCfg-06-01-09 in production. It features a couple of minor tweaks to the alarm limits on the CAL LAC thresholds to cope with the L1Proc switch-over to the new P7_REP calibration constants.
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 (release notes for AlarmsCfg-06-01-08)
- Minor tweaks to the alarm limits on the CAL LAC thresholds to cope with the different calibration constants after the L1Proc switchover to P7_REP.
Reason for change
We request to put AlarmsCfg-06-01-08 in production. It features a couple of minor tweaks to the alarm limits on the CAL LAC thresholds to cope with the L1Proc switch-over to the new P7_REP calibration constants.
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 (release notes for AlarmsCfg-06-01-08)
- Minor tweaks to the alarm limits on the CAL LAC thresholds to cope with the different calibration constants after the L1Proc switchover to P7_REP.
- Relevant thread(s): https://www-glast.stanford.edu/protected/mail/datamon/11260.html
Reason for change
We request to put AlarmsCfg-06-01-07 in production. It features a single minor tweak to the alarm limits to cope with a known problematic ACD channel.
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 (release notes for AlarmsCfg-06-01-07)
- Limits on AcdPedPedMeanDeviation_PMTA_TH1, y_values algorithm, relaxed a little bit for tile 68.
- Relevant thread(s): https://www-glast.stanford.edu/protected/mail/datamon/10917.html