Wiki software last updated 28-Jul-2014 - Comments to Ruben Squartini <ruben@auger.org.ar>

Minutes of the Frascati Meeting

A pdf version of the minutes can be downloaded from here.

Laboratari Nazionali di Frascati, Rome, January 23rd 2006.

Aim of the Workshop

The task of monitoring the detector performance and data quality, can be divided into online and offline monitoring. The aim of this workshop is to provide a tool to check the detector behavior and data quality online for the shifters and give them a the opertunity to react quickly. The long term monitoring issues, for example like uptime calculation, defining quality flags for event reconstructions, etc. should be discussed at the oncoming Malargue Meeting.

The idea for the online monitoring tool is to vizualize both detector performance and data quality. Variables should be considered in two contexts:

  • those to help the shifter online
  • those are useful for post-run diagnostics, which could take place the day after DAQ.

The proposal was to define a small subset of variables available for the shifters, that allow them to react fast on problems. The post-run diagnostics must be done by someone else the next day and is forseen to check all variables that allow a complete classification of that night and diagnose problems. The set of these histograms can be larger and it will take up to one hour to check all histos.

Agreed List of Monitoring Variables

see Variables.

Display Functionality

  • we want only one single display tool
  • the input from the shifter crew should be minimal (i.e. automatic plot production)
  • alarms: there is a separate window keeping history of all active alarms apearing and a classification/severity level of them (warning, acknowledged,serious…) and action of the shift crew.

In addition an alarm window should pop-up as long as the alarms has not been acknowledged by the shifters. This should be independent from the monitoring s/w.

  • Organisation of the Information: There was a discussion to organize the display eye- or telescope-wise:

We agreed that the most convenient way is to organize the GUI eye-wise, but there should always be condens information on a side bar visible (i.e. alarms, stop watches,…). There is always the possibility to provide telescope-wise information in a later stage.

  • Updating: we agreed that when opening a page one always obtains the current status. We should forsee the possibility to stop automatic updating and go back in the history.
  • dependecies: we agreed that the tool should have a minimum amount of external dependencies and libraries. How this can be achieved have to be worked out in the context of technical imlemetation later.

Idea of the general display concept (on Friday we agreed that this concept should merge into the General Tab on the Monitoring page):

Technical Aspects

Paolo summarized the data flow per night:

  • total bandwidth: 2Mb/s/Eye
  • actually we use ~500Kb/s/Eye for FD+Lidar, ~ 300Kb/s/eye Lidar-only
  • Calibration: 2x 600Mb/Eye
  • BgLoop: ~800Kb/Eye/30sec ~ 30Kb/Eye/s (total: 100Mb/Eye/night)
  • shower candidates (T3): 100Mb/Eye/night
  • Laser data: 500Mb/Eye/night
  • Readout logfile: 70/Mb/eye/night
  • Trigger rate: T2=0.1 Hz/mirror, T3=0.02-0.05 Hz/eye

We started discussing how to organize the data centrally. Two concepts are under investigation: using a big ascii file or a central database. At the end of the day there was no clear agreement which concept to implement the discussion was, skipped to the tuesday session.

Visualisation can be provided using php-scripts, either deriving plots from root or using directly the php-internal draw library: jpgraph. By this we get rid of most external library dependencies.

Laboratari Nazionali di Frascati, Rome, January 27th 2006.

GUI

We agreed on the following basic scheme for the monitoring tool:

  • There should be a top bar that is always visible and caontains alarm buttons
  • The usual starting point is a tab called general, that is setup in the way we discussed on monday
  • The Eye tabs contain informations for each eye that can be subdivided into 4 groups: DAQ-Trigger, Calibration, BG_Loop, Laser/Stereo
  • Choosing one of these subclasses one can choose the variable of interests or enters a general page about that eye
  • There will be a tab for alarms, that shows the history of all alarms

The concept can be summarized as follows:

— – HeikoGeenen 30th Jan 2006 –


Log In