Page History

As the instrument evolves, alarm limits for data monitoring sometimes have to be changed. New limits are developed by the data monitoring team in cooperation with the subsystem experts, and deployed by the L1 maintainers. L1 uses symbolic links with fixed names pointing to the current version so they can be changed without changing L1.

Step-by-step guide (updated on 09 Feb 2024)

1. Data monitoring folks make a CCB request to deploy new limits. Wait for that to be approved..
2. The following steps MUST be performed from a rhel6 node (do NOT attempt to deploy alarms on the S3DF).
3. To figure Figure out where the limits are:
   1. Go to the L1 install directory (currently /afs/slac.stanford.edu/g/glast/ground/PipelineConfig/Level1/5.6, look for L1ProcROOT in the environment dump in the log file for any L1 job9)
   2. grep alarmCfgBase config.py (currently the current location is /afs/slac/g/glast/ground/releases/volume11/AlarmsCfg)

4. Go

   there, then AlarmsCfg

   to the location of AlarmsCfg and check out the code from github:

   Code Block
   language bash
   export tag=AlarmsCfg-07-00-37 #or whatever your tag is cd /afs

   Check out the codeCurrently in CVS at /nfs

   /slac/g/glast/ground

   /cvscvs co -r AlarmsCfg-07-00-10 -d AlarmsCfg-07-00-10 dataMonitoring/AlarmsCfg (or whatever the current tag is)

   /releases/volume11/AlarmsCfg wget -O - https://github.com/fermi-lat/AlarmsCfg/archive/$tag.tar.gz | tar xzv mv AlarmsCfg-$tag $tag

5. Remove the current links for test, dev, and prod, and replace them with the new version
6. If possible, switch the links in between deliveries. It is acceptable to have a mix of old and new configs for a run
7. Update the CCB request

...

1. item in JIRA and mark it "Implemented"

Related articles

...

...