Muon Tracker Online Monitoring for Run-3

Instructions for the shift crew can be found here ..

This page contains some basic info regarding (incl. instructions for how to run) the muTr Run-3 online monitoring. Pls consider this to be a work in progress. This document will hopefully evolve together with the online monitoring code.

User interface/GUI/Histogram appearance

One of the more important parts of the online monitoring, is the plots that the user/shift personnel sees. The basic idea is to keep this as simple and informative as possible. The plots below show the result of a second iteration.

The plots are:
Top left: Fraction of channels that were on (Zero-Suppression ratio) vs packet number. TProfile.
The version that is now in CVS does a 'normalization' between the different stations to account for the fact that despite that the stations cover the same solid angle, they have a different number of strips per plane and octant, i.e. a given strip covers a different solid angle in the different stations.

Top right: Number of clusters that were found per event per plane. TProfile.
This is basically the same info as in the top left plot, but using a geometrical unit (octant, gap, plane) for the binning instead of the fem/packetid. So, no 'normalization' is needed for this one.. However, I do multiple the contents found per plane by the number of octants to have the vertical scale be an estimate of the multiplicity seen in the muon arm. I'm not doing any attempts to track the particles, so this just the hit multiplicity.

The top two plots could be indicative of readout problems (left), or HV or related problems (right). The checking done for these are to see if the activity levels are between some min and max boundaries. Note that the absolute scale however depends on the trigger selection.

Bottom left: Signal distribution. TH1F.
There is one curve for single strips and one for clusters (group of adjacent strips that are on/not zero suppressed). The number of strips in a cluster included in the plot is 2,3 or 4. The checking done for this plot is to find the bin for the peak in cluster adc distribution. The peak should be about 200 if the gain is right. The peak finding is done from adc=20 and upwards to avoid getting stuck around 0.

Bottom right: Amplitude vs Time. TProfile. Here we look at the output from the different samples to see if the timing is ok. If it is, the latter 3 samples should be roughly the same with the middle one (Time = 6) highest. If there's a significant slope to the latter 3 samples, the set timing is not ok. The blue histogram is for straight (non-stereo) and the green for stereo planes.

The top two plots have borders between the stations indicated by blue vertical lines, and warning borders (min and max values) indicated by red horizontal lines. The bottom two plots have informational messages with the error summaries to the right.

5000 dAu events, not recorded using the EventBuilder (hence the strange time), were used to produce this plot. It has been suggested that the large spread in the average occupancy per packet could be due to that different packets are biased towards longer or shorter strips. (If all channels are equivalent in terms of efficiency and noise, the occupancy is a measure of the solid angle covered by the strips in the packet).

Message text information

The informational text on the plots are the main messages to the shift crew/users. Output that can help localize problems are echoed to standard out and can be logged, digested and used to address the problems by the experts.
The text in the upper two pads informs the user of the station by station average occupancy and multiplicity estimates. The text on the lower left plot informs where the cluster peak strip was found (range of the bin where it was found). I also call this the Landau peak. Information on the ratio between the Landau and Saturated (at high ADC values) peaks is also printed. For the ideal operation, the Landau peak should be at around 200 ADC counts and the Saturated peak should be small. No error check is presently done on the ratio between the two.
Error messages are put in the lower right pad. Which errors are printed is determined by the found errorcode, also shown in the red or green panel between the upper and lower plots (to the right). Left of this panel, the run number, number of processed events and the found timestamp is given.

The error codes presently used are:

Bit Error Message
0x01 High Zero-Supp ratio
0x02 Low Zero-Supp ratio
0x04 High activity per plane
0x08 Low activity per plane
0x10 Packet errors
0x20 Incorrect timing
0x40 High gain
0x80 Low gain

The warning limits/cuts are set in the file online/monitoring/Run3/subsystems/mutr/MutrMonDrawConsts.h. To change some cut condition, modify your local copy of the file and rebuild the library. To make the new, hopefully improved, cut available to others, commit it to CVS a la:

> klog silvermy
> cvs -l ci -m 'silvermy - new occupancy lower limit + 
require at least 2 packets to be below limit to signal an error' 
MutrMonDrawConsts.h 

Code location

The online monitoring software has been upgraded to use a similar style as the mutr calibration software, and now in the new Run-3 framework. Its all in CVS under
online/monitoring/Run03/subsystems/mutr
with the run_*.C macros used below, in the online/monitoring/Run03/macros directory.

Examples of usage

Here follows an example ROOT session, executed in the mutr/macros subdirectory. (I deleted the ROOT startup banner)
Of course you need to have installed OnlMon libraries in your LD_LIBRARY_PATH. For general instructions on how to build and so on (follows normal PHENIX procedure), see the documentation by Chris Pinkenburg.

For a quick summary of what to do to get going, here's what I did as phnxmutr on va011:

mkdir silvermy/onlmon
cd silvermy/onlmon/
cvs -l co -d . online/monitoring/Run3
mkdir build install
cd build/
../autogen.sh --prefix=/home/phnxmutr/silvermy/onlmon/install
make install
setenv LD_LIBRARY_PATH \
"/home/phnxmutr/silvermy/onlmon/install/lib:$LD_LIBRARY_PATH"
cd ../macros
# make a link to your favorite prdf file before running
# ln -s myfavoriteprdffile data.prdf
root -l
root [0] .x run_mutr.C 

elcome to pmonitor.  Type phelp() for help 
creating server thread
 MutrInit 
 initMapping 
 initMapping done
 initHistos 
 initHistos done 
 MutrInit done 
Getting MUTR calibrations: Time is 2003 6 30 22 30 0
BankID = 2
Insert   : Mon Jan 13 18:23:13 2003
StartVal : Mon Jan 13 17:24:00 2003
EndVal   : Tue Jul  1 00:00:00 2003
Calibration Description : muTr calibration from 13 January 2003
User Name = Unknown
number of entries: 43968
../../../subsystems/mutr/MutrMon.C:484:  - overwriting map with database/calib info 43968 entries stored 
MUTR calibrations retrieved
root [1] 
root [1] prun(5000)
MUTR : INCORRECT CELL ADDRESSES !!! pkt = 11256, cells = 14, 19 20 22
..
MUTR : INCORRECT CELL ADDRESSES !!! pkt = 11256, cells = 17, 23 24 25

..and in another root session..

root [0] .L run_mutr.C 
root [1] mutrDrawInit() 
root [2] mutrDraw()
No Recv, Server not running on localhost on port 9081
No Recv, Server not running on localhost on port 9082
No Recv, Server not running on localhost on port 9083
No Recv, Server not running on localhost on port 9084
No Recv, Server not running on localhost on port 9085
No Recv, Server not running on va001 on port 9082
No Recv, Server not running on va001 on port 9083
No Recv, Server not running on va001 on port 9084
No Recv, Server not running on va001 on port 9085
No Recv, Server not running on va002 on port 9081
No Recv, Server not running on va002 on port 9082
No Recv, Server not running on va002 on port 9083
No Recv, Server not running on va002 on port 9084
No Recv, Server not running on va002 on port 9085
found histo mutH1ClustAdc[0]
 MutrMonDraw Arm S 6 planes below set limit (numbering starts on 1) :
Sta1Oct8Pla1 Sta1Oct8Pla2 Sta1Oct8Pla3 Sta1Oct8Pla4 Sta1Oct8Pla5 Sta1Oct8Pla6 
 MutrMonDraw Arm S: ClusterLandauPeak 3284 ClusterSaturatedPeak 339 Ratio 10
 MutrMonDraw Arm N: ClusterLandauPeak 2821 ClusterSaturatedPeak 405 Ratio 7
 MutrMon::Draw packet 11256 has 0.0738887 errors 
root [3] .q

This output was from the session used to produce the plots for the shift crew.

Logbook entry for run6: changing monitoring trigger configuration

The online monitoring code can be checked out from:

online/monitoring/Run3
Our mutr code will be found then in:
online/monitoring/Run3/subsystems/mutr

0) How to build locally mutr CVS code

To test locally, I used a local setup:
/home/phnxmutr/Cath/source
where you find the mutr files (as in cvs):
/home/phnxmutr/Cath/source/subsystems/mutr
a local build:
/home/phnxmutr/Cath/build
One should use the autogen.sh file from
 online/monitoring/Run3/
online/monitoring/Run3/autogen.sh --prefix=INSTALLDIR 
where INSTALLDIR refers to your local libraries, for me:
/home/phnxmutr/Cath/library
One can create his own local directory or use that one to test the changes made in the files.
More instructions can be find here: subsystem_programmers.

1) How to change the trigger

The main code is MutrMon.C which has the main function
 int MutrMon:: process_event(Event *e). 
Among the first lines of this function you have the trigger selection:
**********
OnlMonServer *Onlmonserver = OnlMonServer::instance();
//if (! Onlmonserver->Trigger("ONLMONBBCLL1") ) // we used for run5
if (! Onlmonserver->Trigger("ERTLL1_4x4c&BBCLL1") ) // used for run6 200
{ // no BBC live interaction trigger - skip this event
// return 0; // chris just changed to no trigger selection at
all a few hours ago
}
**********
For run 6, the trigger was chosen from daq monitoring to have the highest rate: ERTLL1_2x2
To chose the trigger, one has to look at the DAQ run control summary, and prefer the trigger that has the highest trigger rate and lowes scale down count, in oder to run the monitoring on a lot of events. For run7, the mutr online monitoring is triggering with the min bias trigger difined by Chris.

2) How to hange the thresholds of the monitoring

Each beam set up and monitoring trigger (or DAQ trigger) may imply changing the monitoring references (thresholds that controls the error messages ont he monitoring of the OS).
Once you changed the trigger, you need to change this threshold per package.

The limits used are set in MutrMonDrawConsts.h . The values are used in MutrMonDraw.C . There following lines are the thresholds:

******
cconst float YMINPLANES[2] = { 0.02, 0.02};// limits for 62GeV pp
const float YMAXPLANES[2] = { 1, 2}; // limits for 62GeV pp
const float YMINPACKETS[2] = { 0.00001, 0.00001};// limits for 63GeV CuCu run + 62GeV pp run6
const float YMAXPACKETS[2] = { 0.1, 0.1}; // limits for 63GeV CuCu run + 62GeV pp run6
******
We usually set the limits to 10 times the average. So take the average from a good run and you set the lower limit to roughly 10% of that and the upper limit to 10 times that value. One can check that this was the case with the previous configurations.

3) Test your changes before commiting to CVS

It is better to test locally the changes, running a monitoring client (see here for details).
Before starting root, one needs to load his local labrary. In my case I type the followong command:
setenv ONLMON_MAIN /home/phnxmutr/Cath/library
source setup_onlmon.csh

After testing the changes, one needs to commit, send a mail to Chris saying that he can include the mutr CVS changes in the next build.
All monitoring than are updated.



silvermy@lanl.gov 2002

Last modified: