MON00

The Year2000 Baikal Online Monitor Program

User`s guide, Release MON00.C.12, 2000

April 14th, 2000

What is MON00

MON00 is the year 2000 version of the Baikal Online Monitor Program. In this paper, we describe all extensions and changes with respect to MON96, the 1996 release of the Monitor Program.

The Baikal Online Monitor Program runs on the "Monitor PC" (an 486/386 IBM-PC), that is part of the DAQ in the shore station of the Lake Baikal Neutrino Experiment. This F77-program is an intelligent user interface to access the information stored and processed on the shore station transputer modules ("LIM"-modules). It gives access online or offline to any of the more than 1000 histograms that inform in detail about the status of the various detector- and DAQ-components that form the NT-200 array.

For all features available for the 1996 version, MON96, and for details on installation, we refer to the MON96 User's guide, available online from the Help Submenu, as well as on the web (http://www.ifh.de/~wischnew).

Features and topics described there in detail are in particular:

• Online/ Offline Operation Modes
• Menu/ Submenu/ Histogram Functionality
• Muon/ Monopole/ Supernova/ ControlPoint Data
• User-Analysis for Muons.
• LIM_Backup/ AutoPilot Features
• Graphic HardCopy Interface

After the 1996 release MON96, releases were: MON98.B.03 in April 1998 (and June 1998, to enable LIM generated LTS-histograms) and the current release MON00.C.12, April 2000. The LIM software was updated in March and June, 1998 (LIM 98.01.00) and on March 25th, 2000.

The new features are essentially:

• Muon-Data Quality Analysis
• LTS data
• Miscellaneous: DOS-shell, ScreenSaver, ...

It was the intention of the year 2000 upgrade, to present to the user an easy-to-check summary of the current status of the NT-200 detector. It should give a first indication for failures of channels or specific problems concerning the recorded ADC or TDC information. In particular these interfaces are to be used by the operator during the data taking process. For this purpose, the Quality Analysis Table and the LTS Summary pages have been introduced. After consulting these main summary table, the operator is invited to check for details concerning the problematic channels or optical modules in some of the many hundreds of histograms available in the Baikal Monitor System.

This effort is planned to be extended to a more sophisticated system, after initial experience with the current, rather simple quality analysis algorithm will have been gained. In particular, we expect to fine tune the cut-values that are currently in use to define abnormal-TDC, unstable-ADC and quasi-dead channels.

The Monitor program has been developed in close and fruitful collaboration with H.Heukenkamp (LIM software), S.Klimushin (Host-PC software) and D.Petukhov (Host-PC and LIM software).
In case of bugs, questions, remarks or suggestions, please contact per e-mail: wischnew@ifh.de (Ralf Wischnewski) .

Quality Analysis

The quality analysis is checking the muon induced channel response for consistency with expectations. Currently analyzed are the following informations:

• Hit rate for every channel under the global majority (multiplicity) muon trigger condition,
• Amplitude distribution for each channel,
• Absolute TDC-time (in codes) for each triggered channel.

The Quality analysis submenu has been added in April 2000, to:

• Enable the operator to gain a quick overview about the main performance of the NT-200 array under the muon trigger,
• Compare the current status to a "Quality Reference File", and draw quick conclusions about possible instabilities, to trigger measures to "revive" problematic or failing channels,
• Store run based information on the muon response of all channels in an effcient way to a small-size output file. This "Quality Reference File" file
  • is available as part of a simple data base to check the NT-200 performance during the ongoing data taking process ("quasi-online", i.e. much earlier than the raw data files are analyzed offline),
  • can act itself as the reference file that another run can be compared to.

It is recommended, to write the Quality reference files (qrf-files) on a regular basis, i.e. at the end of each run, just when the LIM_Backup files are written. Sending these short qrf-files on e.g. a daily/weekly basis to Moscow allows for very early detection of problems with the NT-200 performance.

The following two menu functions are available, starting from TopMenu "Run Tables":

• "Show Quality Table" (SubMenu: Quality Table) A summary table for Muon data of the current run displays the status of the array and compares the the reference run LIM_Back/stand.qrf (which is set fixed, not selectable as in the LTS-menu). We have in the table information on:
  1. Dead Channels. A dead channel is defined to have no muon hits for the given run. 1.1. Total number of dead channels 1.2. List of dead channels 1.3. Total number of dead channels that are different from the dead channels in the quality reference file 1.4. List of dead channels different for the current and the reference file (Note: additional dead channels can occur, as well as formerly dead channels can disappear. I.e. the maximal number of channels reported to be different can be the sum of the total numbers of dead channels in both runs.) In case no reference file stand.qrf was found, or if the file is for a different detector configuration, a warning is printed, and the comparison is omitted.

  2. Quasi-Dead Channels. A quasi-dead channel is defined to have significantly less muon hits than the average taken over all non-dead channels. Currently, the cut is set to a channel rate less than 1% of the average rate. 2.1. Total number of quasi-dead channels 2.2. List of quasi-dead channels 2.3. Total number of quasi-dead channels that are different from the quasi-dead channels in the reference file 2.4. List of quasi-dead channels differing from the reference file (Note: additional quasi-dead channels can occur, as well as formerly dead channels can disappear).

  3. ADC spectra stability check. A check is done for the relative variation of the average and the sigma of the amplitude distribution for every channel, with respect to the quality-reference run. Currently, a channel is defined to be "unstable", if its variation exceeds 20% and 40% for average and sigma, respectively (these parameters need to be tuned). 3.1. Total number of ADC-unstable channels 3.2. List of channels.

  4. Scan for abnormal TDC data. A scan for the TDC trigger times is done for every channel. If the fraction of TDC values in the very-low TDC interval [0,100] exceeds a given value (set to 5% currently), the channel is flagged to have bad TDC information. As an example, for parts of the 1999 season channel 76 was showing this feature. 4.1. Total number channels with abnormal TDC-codes 4.2. List of channels.

  5. Scan for extreme ADC spectra. A scan for the average amplitudes of all channels is done (uncalibrated amplitudes). If the average is below 10 or above 300 codes (current settings), the channel is flagged to be strange in ADC. 5.1. Total number channels with extreme ADC-average 5.2. List of channels.

• "Write Quality Reference File" (SubMenu: Quality Table) From this menu, a Quality Reference file is generated for the currently analyzed run (in online or offline operation modes). The user is prompted for either automatic filename (from the runname), or arbitrarily chosen filename ("Free Filename"). If the filename already exists, a decision about deleting the old file has to be made. The file extension is set to .qrf, e.g. for run r0058.mon the qrf-file will be ./LIM_BACK/r0058.qrf. The file is written in a simple and well commented ascii-format. It contains
  • Header: number of channels in configuration, runname, startime and duration, total number of muon trigger
  • Number of muon trigger for each channel
  • Average and sigma of amplitude distribution for each channel
  • List of dead detected channels
  • List of quasi-dead detected channels.

For a standard quality check by the NT-200 operator, one requests to check all the above mentioned items. For reported problematic channels, the corresponding histograms must be inspected (e.g. the amplitude histograms if an unstable amplitude is reported for a channel, or the TDC-histogram for an abnormal TDC channel).

About all findings, the array supervisor (Sergei Klimushin) should be informed, to recommend corresponding actions.

Please note, that all the cut-values used to flag channels as bad or problematic, are "first guess" values. They need better tuning, after some experience over the next months.

After a significant and permanent change of the detector setup (e.g. after some additional channels died), a new quality reference file stand.qrf needs to be defined. This is simply done by copying a qrf-file generated by "Write Quality Reference File" to the Quality Reference file stand.qrf.

Local Trigger System (LTS) - Histograms

The Local-Trigger-System (LTS) is recording the local trigger pulses sent by every individual channel to the corresponding String Controller. The LTS counts the number of local trigger pulses arriving per LTS sampling time interval. This sampling time interval can be set by the Host-PC to 0.8192 sec or 1.6384 sec (standard is 0.8192 sec). The LTS data are send with the fast muon-data stream to shore and written to the raw data file as well as analyzed within the LIM.

The LTS data do present a full time mapping of all trigger pulses generated by each channel, sliced into time windows of fixed length. They are practically deadtime free, contrary to the data from the Control Point System, which has a low sampling rate (one sampling per 2 minutes typically) and is sampled only on request from the HostPC.

LTS data are taken since 1997 and written to the raw data files. They are histogrammed on the LIM since June, 1998. The new LTS Monitor menu items to the Top Menu have been added in 1998, and were updated in 2000. All relevant LTS histograms are stored in the Monitor generated LIM_Backup files since June, 1998.

The LTS-submenus are:

• "String Multiplicity" (SubMenu: LTS-Histograms) The first histogram gives the total number of times that for any channel on a given string a valid ("good") LTS record was detected. Correspondingly, for a string with all 6 channels reporting properly LTS-info, the number of entries will be 6*number-of-LTS-time-slots. For the LTS system we basically find, that a given string either works properly or failing completely. A second histogram gives per string the number of detected "bad records". This histogram should be empty for runs with good LTS information. Only for runs taken prior to March, 2000, the histogram will have 2 entries per string for most runs (this is the first 2 records per string, which are "bad" by definition; they are ignored for LIM-histogramming since the LIM upgrade in March, 2000).

• "Rate Distribution" (SubMenu: LTS-Histograms) Gives for each channel the distribution of the LTS-measured local trigger rates, R_lts, defined for each LTS sampling time interval T_lts as R_lts = N_Counts/T_lts, with N_Counts the number of hits recorded by the LTS-counter. For a channel operating normally, this distributions should follow a Poissonian around the average value.

• "Rate versus time" (SubMenu: LTS-Histograms) The LTS measured local rate, R_lts, for every channel is given as function of time since runstart. The rate is averaged over a few sampling intervals in the LIM (e.g. set by the HostPC to n=10 intervals = 8.192 sec since April, 2000). With the 1000 time bins available per channel, the total time span currently covered is 1000*n=10000 secs. The rate-versus-time histograms are included into the LIM_backup files since June, 1998. While this information has not been accessible in the 1998 Monitor version, with the MON00-upgrade this information is avaliable for all new as well as for all old runs. Please note a minor difference in the absolute time scale for these plots: For data taken after March 25th, 2000, the time scale is given in absolute time (as for the Muon Rates, Monopole and ControlPoint versus time). For all LIM_backup files written earlier, the time scale is starting from "0. hrs" at runstart.

• "Summary for all channels" (SubMenu: LTS-Histograms) This submenu gives a complete overview on the array behaviour concerning the local trigger rates. It' s main idea is to check for the overall array performance to identify bad channels (high rate or highly unstable), and to verify the stability of the arry by comparing to LTS data from a reference run a freely selectable reference run. Several submenu functions allow to:
  • Create New Reference File (SubMenu: Summary for all Channels) Store LTS statistics data for the given run for all channels in an output file (LTS-reference file: "LRF"-file, e.g. r0058.lrf, which is in a simple ascii-file format). This LRF-file can further on be used as a reference file, so that another run may be compared to this.
  • Select Input Reference File (SubMenu: Summary for all Channels) Select a reference file (LRF-file) from the set of earlier generated reference files (see above menu item "Create New reference File"). After this file has been read into memory, the avearge and sigma values of that run are used to compare the current run to.
  • Display Summary (SubMenu: Summary for all Channels) This is the essential summary of the array status with respect to the local trigger rates. Four summary plots are produced from all the LTS rate histograms available:
    1. Average local rate versus channel number Gives the average of the rate from the above discussed LTS rate distributions (in Hertz), as function of channel number.
    2. Sigma local rate versus channel number Same as 1. but for the sigma (RMS) of the rate distribution (in Hertz), as function of channel-number.
    3. Sigma(Rate)/Sigma_Poisson versus channel number As function of the channel number, the ratio of sigma (plot 2.) and the poissonian expectation from the average (plot 1.), which is given by sqrt(average), is plotted. This plot gives an easy handle to identify channels with the shape of the LTS-rate distribution dominated by other effects but purely statistical fluctuations.
    4. Current average rate/average reference rate versus channel number For each channel, the ratio of the average LTS-rate for the current run and the average for the same channel as given in the selected reference run is calculated and displayed as function of the channel number.

Miscellaneous

On top of Quality Analysis and the LTS interface, a few minor features have been added to the Monitor program in 1998 and 2000.

• DOS Shell (Top Menu) From the Top Menu the user can access a DOS shell. Any program not using the DBOS memory manager can be started. For example, it is possible to edit data-files, or to start another NortonCommander to handle some files etc. Return back to DOS is via the command exit. It is not possible to run the FTN77-compiler.

• Screen Saver for normal menu A screen saver is activated after a few minutes, if the Monitor program is in any of the normal menu-functions. The screen saver is SSAVERS:\stars.com, relative to the monitor directory. The screen saver is not activated if a monitor menu with parameter editing option is activated (e.g. a filename request), or from any of the graphical histogram-presentations (HPLOT/HIGZ).

This document was generated on 14 April 2000 using the texi2html translator version 1.51.