Blog from December, 2014

Request to update alarm settings
simone maldera posted on Dec 31, 2014

Reason for change

We request to put AlarmsCfg-06-05-00 in production. The new tag implements a few changes  to the alarm limits on the 20MHz clock frequency, 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

SSC-390 - Getting issue details... STATUS

Details (release notes for AlarmsCfg-06-05-00)

Relaxing the alarms limits on the 20MHz clock frequency deviation.

  In digi_eor_alarms.xml and  fastmon_eor_alarms.xml: upper limits for x_average of Tick20MHzDeviation_TH1  raised to -150(warning) and -100(error)

  In digi_trend_alarms.xml: upper limits for Mean_Tick20MHzDeviation  raised to -150(warning) and -100(error)

Relevant thread(s):

https://www-glast.stanford.edu/protected/mail/datamon/13785.html

Request to deploy L1Proc 4.9
Warren Focke posted on Dec 18, 2014

Reason for change

IGRF-11, our magnetic field model, will expire at the end of the year. The new version has not been released yet. Even if they release it while I'm typing this, there's not enough time left to get FastMon and astro fixed. Both astro and the FastMon IGRF library will ignore the time validity limits on the model if the IGNORE_IGRF_BOUNDARY environment variable is set (to anything). This release puts a switch in the config file to do this for all the jobs that require it.

Other changes from 4.8:

A new version of Monitor that checks whether it actually managed to write its output

Changes to batch priorities that should do a better job of keeping the farm busy when we are swamped with data.

Test Procedure

We have processed a current LPA run in the DEV pipeline with this version of L1Proc, with the time boundary switch on and off. We don't have new data to test on.

Rollback procedure

We can easily switch back to the previous version of L1Proc.

CCB Jira

CCB request: Request to deploy L1Proc 4.9

Details

L1Pipeline: L1Pipeline-04-09-00

  • add a switch to set IGNORE_IGRF_BOUNDARY for the jobs that need it
  • change batch priorities to utilize the farm better

dataMonitoring/FastMon: FastMon-05-03-03

  • bug fix when calculating dates for inptu to IGRF model.

dataMonitoring/IGRF: IGRF-02-01-01

  • ignore validity time range if env var IGNORE_IGRF_BOUNDARY is set (to anything)

svac/Monitor: Monitor-02-01-05

  • detect zombie output files

Complete set of tags for L1Proc 4.9

GlastRelease: GlastRelease-17-35-24-lp61

ScienceTools: ScienceTools-09-33-00

svac/L1Pipeline: L1Pipeline-04-09-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-03

dataMonitoring/FastMonCfg: FastMonCfg-02-02-01

dataMonitoring/IGRF: IGRF-02-01-01

svac/Monitor: Monitor-02-01-05

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

 

Request to deploy dataMonitoring/IGRF-02-01-01
Luca Baldini posted on Dec 17, 2014

Reason for change

This version (IGRF-02-01-01) implements a mechanism for preventing the IGRF module from raising an exception when the model date passed to the python module exceeds the time boundaries of the model. Particularly, if the IGNORE_IGRF_BOUNDARY environmental variable is set (no matter what its value is), then IGRF sets the date to 2014.999 if the required date is >= 2015. Note that the change is silent, as we don't want to print one line per event.

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

SSC-388

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

 

Request to deploy dataMonitoring/FastMon FastMon-05-03-03
Luca Baldini posted on Dec 01, 2014

Reason for change

This version (FastMon-05-03-03) fixes a bug in the FastMon package in how we parse the date from the M7 files and cast it to a float to be passed to the IGRF package (to initialize the Geomagnetic model).
The detailed description of the changes is in the last section.

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

SSC-386@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.html