...
From those runs, we need to know absolutely ASAP whether there are any problems with LAC, FLE, or FHE. We need that information at the MOC will need to know whether problems exist within hours after the data come out of the pipeline, if we're to have any chance to fix them before the FLE and FHE timing-in data are acquired. Sorry about that. Please communicate this information to the Shift Coordinator (Rob or Eduardo or ?) at the Mission Support Room at SLAC absolutely as soon as you can, so that he can relay to us in the MOC at GSFC.
Go to the GLAST Data Quality Monitoring pages http://glast-ground.slac.stanford.edu/DataQualityMonitoring/.
Select an appropriate time interval, and click on the run ID.
Click on the "Expert" mode in the upper right corner of the left-hand panel. When you're in "Expert" mode, that word will show "Shifter", and when you're in "Shifter mode, that word will show "Expert", just to be confusing.
To find the number of trigger requests per tower in this run or sum of runs, click on
Root > Digi > GEM > TriggerVectors > CAL_HI map(tower)
Root > Digi > GEM > TriggerVectors > CAL_LO map(tower)
Of course, if one GCFE is hot, one of the towers will be significantly out of family.
To see whether CALLO or CALHI TREQ rate is too high, click on
(hmmm, I'm not sure what to do, yet)
To find the distribution of To find the distribution of CAL hit occupancy, click on
Root > Digi > CAL > Num. logs hit (LAT)
Root > Digi > CAL > Num. logs hit (tower)
If zero suppression is bad, the minimum occupancy won't be zero. If it's really bad, the peak will be somewhere above zero. Find out which tower is causing the problem, or if all towers are.
2. From the initial LPA runs, "measure" the LAC, FLE, and FHE thresholds.
...