TWiki> LHCb/RichOperations Web>RichOnlineMonitor (revision 62)EditAttachPDF

LHCb RICH Online Monitoring

Contact and mailing list

A mailing list has been created: lhcb-rich-onlinemonitor AT cern.ch

The Online Cluster

Getting an account on the online cluster

Send a mail to lhcb-online-admins AT cern.ch and request an account. The accounts are personal and not related to the "normal" CERN accounts (e.g. on lxplus), you'll get a new login and a separate password for the online machines. A group area exists in /group/, so for the RICH group, our area is in /group/rich.

Computer resources available for RICH commissioning

The "HLT" farm dedicated for the RICH commissioning are hlte403 and hlte404.

The main Rich2 control PC is r2ecs01.lbdaq.cern.ch

Using the online cluster

The online network is separated from the normal CERN network, the only way to access the machines is via the gateways, please follow the instructions on the dedicated online page from the online group.

Once you are logged on, you can setup the LHCb software environment with

 > source /group/rich/sw/scripts/setup.sh
Which will give you access to the software installed on the online system. Note that this command sets the User_release_area to the GLOBAL RICH area /group/rich/sw/cmtuser, used for commissioning etc. Changes in this area should be done carefully.

For testing, you can use a different area by changing User_release_area by, e.g.

 > export User_release_area=$HOME/cmtuser
which will change it to use a cmtuser area in your private home area.

Access to the LHCb software repository (CVS) is described here. Note though DON'T use the SSH approach (as currently recommended on those pages) since this will lead to write access problems between different users. Instead run

 > kinit AFSUSERNAME@CERN.CH

where AFSUSERNAME is your LHCb AFS username, to get a kerberos token which will allow the standard kerberos access to CVS to work. You can check if you have a Kerberos token via klist

Once you have done this getpack will work as you are used to on lxplus etc. E.g.

 > getpack Hlt/Moore v2r2

Note though that hltXXX don't have external access - To use CVS you will need to be on one of the common nodes.

DIM DNS

The DIM system uses a DNS to locate available services. At present, our DNS runs on hlte04

CAMERA -Commissioning and Monitoring Error Reporting Application

Camera is a network application specifically built for communication and error logging for the commissioning and monitoring.

Using camera in the control room

Using camera in the control room

Algorithms reporting to Camera

Algorithms reporting to Camera

Camera Gui hints

Camera Gui hints

The Rich Raw Data Format and Decoding Software

The RICH raw data format is described in detail in the EDMS note accessible from this page which details all the LHCb data formats.

The decoding is performed by the Gaudi software implemented inside the Rich/RichDAQ CMT package. The primary method that performs he decoding is implemented in the Rich::DAQ::RawDataFormatTool Gaudi tool, specifically the method decodeToSmartIDs (Rich::DAQ::L1Map &decodedData) const.

The data is decoded into a data structure, Rich::DAQ::L1Map which is designed to map rather closely the structure of the L1 raw data itself.

Rich::DAQ::L1Map is a map containing the L1 board ID as the key, and the target another map Rich::DAQ::IngressMap. This Ingress map contains (up to) four entries, one for each ingress in a given L1 board, where the key is the ingrees ID and the target the a data object of type Rich::DAQ::IngressInfo.

The Rich::DAQ::IngressInfo data object contains two main data parts. The header word for that Ingress Rich::DAQ::L1IngressHeader and a data map which contains one entry for each HPD in that ingress, the Rich::DAQ::HPDMap. This entity is itself (yet) another map which has as its key the RichSmartID identifier for the HPD in question and as its target a Rich::DAQ::HPDInfo data object. The Rich::DAQ::HPDInfo is the final data object in the overall structure, and contains the decoded data for a single HPD, namely the header and footers when available and a vector of the RichSmartID identifiers for each active HPD pixel.

The above description makes the decoded data sound very complicated. In fact, it isn't really and the usage of this data is best done by simply looking at an example where the decoding tool is used. The follow section, which describes the RICH monitoring algorithms, provides various examples of this.

The Online Monitoring Software

The main application and package for the RICH online monitoring software is called Panoptes This package contains the executable for the online monitoring and offline tests as well as the main options files

The following sections detail the (evolving) online monitoring software. N.B histograms and counters published to DIM should be declared in the initialize() method of the monitoring algorithm

N.B The versions of the underlying packages included in OnlineEnv v3r2 and above provide further functionality. However, the monitors need to access data differently and hence versions written for OnlineEnv v3r2 cannot be used with earlier revisions of the online environment

Software tags / releases

The monitoring software is released from time to time with a given tag (or release number) to allow for easy comparison and interaction with other groups. The structure of the tag is as follows vNrMpK where N is the major release number, M the minor release number and K the number of the patch. The latter one is optional and may not be present.

Currently available tags are:

v1r0 Used with version v4r7 of the online software environment

CMT Packages

The online-monitoring software for the RICH detector is split onto several packages:

Rich/RichOnlineMonitors Gaudi-algorithms for the online monitoring, e.g. hitmap monitors, DAQ monitor, etc.
Rich/RichMonitoringTools Tools for the online monitoring, e.g. CAMERA,
Rich/RichMonitoringSys Steering package for the online monitoring, contains the options files, steering scripts etc. (but no source code)

If you need the real hardware and L0 ids installed in Rich2 or SSB2 you can use an alternative slice of the Conditions database. To do this copy the file /afs/cern.ch/user/p/papanest/public/RichDetNumb20070701.db A new file is available at /afs/cern.ch/user/p/papanest/public/RichDetNumb20071220.db which includes the change in the recent database schema (used with Online v4r5 onwards). Then add these options to your job:

CondDBDispatcherSvc.Alternatives = { '/Conditions=CondDBLayeringSvc/CONDLayers' };
CONDLayers.Layers = {'CondDBAccessSvc/CONDLocal', 'CondDBAccessSvc/LHCBCOND'};
CONDLocal.ConnectionString = "sqlite_file:<pathToFile>/LHCBCOND";
For data from Rich2 then use:
CONDLocal.DefaultTAG = "RICH2";
or for data from SSB2
CONDLocal.DefaultTAG = "SSB2";
-- AntonisPapanestis - 01 Jun 2007

Options files

The main options files are collected in the package Rich/Panoptes. This way, no source code needs to be checked out if only the options files need to be modified (once the Rich monitoring package are part of the online environment, at present, all packages need to be checked out from CVS)

In detail, the options files are:

RichOnlineMonitor.opts top-level options file to be used in the online environment when monitoring the RICH detector. Contains the "MDF-magic" for use with the event-builder
TestOffline.opts top-level options file to be used when testing the monitoring algorithms offline with e.g. Brunel, DaVinci or Gaudi.exe (from the Online package). Contains the "MDF-magic" to read previously created files
RichMonitorCommon.opts included by both top-level options files, contains steering options relevant to all monitoring algorithms, etc

The opions files for the individual monitoring algorithms are collected in the package Rich/RichMonitoringSys

RichCommissioningMonitor.opts configuration file specific to this algorithm
RichDAQMonitor.opts configuration file specific to this algorithm
RichHitMapMonitor.opts configuration file specific to this algorithm
RichCornerPixels.opts configuration file specific to this algorithm

Currently implemented monitoring alogrithms

RichHPDNHitMonitor

This algorithm monitors the number of hits in the active HPDs. Number of hits is published as a counter via PVSS. In addition, the same information is available as a 1D histogram per HPD (disabled by default). N.B. The algorithm is not yet operational pending discussions of when/where the relevant entities should be published to DIM via declareInfo(). The algorithm is controlled via the following options

MonitorRate monitor every nth event
FillHistos fill histograms in addition to publishing counters
ExtendedVerbose even more output than verbose()
HistoNHitMin lower left border of histogram showing number of hits
HistoNHitMax upper right borer of histogram showing number of hits
HistoTrendStep number of steps in trend histogram

RichHitMapMonitor

Provides hit-map histograms of each RICH detector and each HPD panel
DoAliceMode fill histograms in ALICE mode
OutputLevel verbosity level
N.B. When running in alice mode, the lhcb mode histos are unusual, though, in that the hits in subpixels are added up int one LHCb pixel. instead of being just digital (per event) So 3 different subpixels hit increases bincount by 3 nstead of just 1.

RichDAQMonitor

This algorithm monitors the data-aquisition by checking the various header words, compares the information between the headers and verifies that the data can be read out correctly
AlertRate number of events after which all alerts found in the past events are sent to the error reporting tool
MonitorRate pre-scale for this algorithm, monitor only each nth event
SendAlertMessages send alert messages to error reporting tool (true by default)
SendAlertDirect do not accumulate alert messages but send them directly to the error reporting tool as they occour
OutputLevel verbosity level

RichCommissioningMonitor

This algorithm has been transferred from the Rich/RichTestBeamTools package and is based on version RichOnlinePixelDisplayAlg.h version 1.6 and RichOnlinePixelDisplayAlg.cpp version 1.10. It publishes the following information via DIM
  • as a summary
    • 2D histogram showing all hits in all HPDs (in terms of pixel row and column)
    • 1D histogram of the inclusive distribution of the number of hits of all HPDs
    • 1D histogram of the number of hits of all HPDs as a trend plot
    • the number of hits of all HPDs as a counter (real-valued number)
    • the moving average of the number of hits of all HPDs as a counter (real-valued number)
  • Per HPD
    • 2D histogram of the hit distribution (in terms of pixel row and column)
    • 1D histogram of the inclusive distribution of the number of hits
    • 1D histogram of the number of hits as a trend plot
    • the number of hits as a counter (real-valued number)
    • the moving average of the number of hits as a counter (real-valued number)

The algorithm is controlled via the following job options

EventMoniRate event rate to be monitored, e.g. 10 corresponds to monitoring only every 10th event
PurgeHistos reset histograms after given number of events monitored
EventsPerFile number of events after which the histograms are reset (if PurgeHistos = true)
NTrendSteps number of entries in trend plot
histoCounterMin lower (histogram border for inclusive hit distribution)
histoCounterMax upper (histogram border for inclusive hit distribution)
MovingAverageEvents number of monitored events over which the moving average is calculated
MonitorRich1Panel0 (true/false) monitor panel 0 of Rich1 (since v1.2)
MonitorRich1Panel1 (true/false) monitor panel 1 of Rich1 (since v1.2)
MonitorRich2Panel0 (true/false) monitor panel 0 of Rich2 (since v1.2)
MonitorRich2Panel1 (true/false) monitor panel 1 of Rich2 (since v1.2)
MonitorRich1Columns vector of integers specifying the column in Rich1 to monitor (since v1.3)
MonitorRich2Columns vector of integers specifying the column in Rich2 to monitor (since v1.3)
AliceMode switch to ALICE mode for histograms (since v1.7)

N.B. The columns for the options MonitorRich{1,2}Columns are identified by a single integer as panelNr*10+colNr

N.B. Versions 1.5 of RichCommissioningMonitor.cpp and v1.4 of RichCommissioningMonitor.h and above are compatible with OnlineEnv v3r2 and above

HotPixelReport and SoftPixelMask

Used to create and apply masks for masking of hot pixels and testpatterns.

Here is a short description of how to use it:

1) run /group/rich/scripts/hotpixelmon.sh to produce the pixelmasks. They will be created as option files in the directory, where the script is run. Wait for at least 10000 Events and check, that the files make sense. The numbers describe pixels in a readable way: e.g. 2011431000 is Rich 2 Side 0 column 11 row 4 pixelcolumn 31 pixelrow 00 and subpixelrow 0

2) The files are produced every 1000 events and called HotPixelAB-NNNN.opts. A means Rich I (0) or II (1) B is A (0) or C(1) side. the NNNN denotes the number of Events, that have contributed to the file.

3) Copy the files HotPixel10* and HotPixels11* to cmtuser/Online_v3r3/Rich/RichMonitoringSys/v1r0/options/ and name them HotPixels10.opts and HotPixels11.opts

4) Now change the first line of both of these files to from HotPixels += { to HotPixels += { as the name of the aLHCb.Algorithm that reads them is SoftPixelMaskPost .

RichCornerPixels

This algorithm is to be used in conjunction with the HPD test pattern that illuminates the four corner pixels. Produces a series of histograms that display only those four corner pixels as bins in order that each HPD can be visually inspected to ensure that it is sending data.

It publishes the following information via DIM

  • as a summary
    • 2D histogram showing all corner pixels hits in all HPDs (in terms of pixel row and column)
    • 1D histogram of the inclusive distribution of the number of corner pixel hits of all HPDs
    • 1D histogram of the number of corner pixel hits of all HPDs as a trend plot
    • the number of corner pixel hits of all HPDs as a counter (real-valued number)
    • the moving average of the number of corner pixel hits of all HPDs as a counter (real-valued number)
  • Per HPD
    • 2D histogram of the corner pixel hit distribution (in terms of pixel row and column)
    • 1D histogram of the inclusive distribution of the number of corner pixel hits
    • 1D histogram of the number of corner pixel hits as a trend plot
    • the number of corner pixel hits as a counter (real-valued number)
    • the moving average of the number of corner pixel hits as a counter (real-valued number)

The algorithm is controlled via the following job options

EventMoniRate event rate to be monitored, e.g. 10 corresponds to monitoring only every 10th event
PurgeHistos reset histograms after given number of events monitored
EventsPerFile number of events after which the histograms are reset (if PurgeHistos = true)
NTrendSteps number of entries in trend plot
histoCounterMin lower (histogram border for inclusive hit distribution)
histoCounterMax upper (histogram border for inclusive hit distribution)
MovingAverageEvents number of monitored events over which the moving average is calculated
MonitorRich1Panel0 (true/false) monitor panel 0 of Rich1
MonitorRich1Panel1 (true/false) monitor panel 1 of Rich1
MonitorRich2Panel0 (true/false) monitor panel 0 of Rich2
MonitorRich2Panel1 (true/false) monitor panel 1 of Rich2
MonitorRich1Columns vector of integers specifying the column in Rich1 to monitor
MonitorRich2Columns vector of integers specifying the column in Rich2 to monitor
AliceMode switch to ALICE mode for histograms

The screen-shot shows algorithm in use with the Gaudi Online Monitor RichCornerPixels.png

The displayed histograms are as follows:

Upper left histogram
each group of 4 corner pixels for all HPDs in RICH2, where there is a 1 bin gap between each HPD;
upper right histogram
an individual HPD and it can be seen that the bottom right corner pixel was not seeing the test pattern;
bottom left histogram
total number of corner pixel hits that were seen per event;
bottom right trend
same information as at the bottom left histogram, this time the total number of corner hits are plotted against the event number.

Monitoring using the special "Calibration" trigger

A special "calibration" trigger is foreseen which can be used by the various sub-detectors for dedicated tasks (e.g. flash a laser, etc). These events use a dedicated trigger and the resulting data is sent to the CalibrationFarm (~1 or 2 PCs) which analyse these special events. In contrast to other monitoring algorithms, the algorithms analysing these events operate on a dedicated single event and base their findings on this event only, whereas the other online monitoring events (in general) determine statistically significant quantities from multiple events. To obtain the relevant trigger information inside the Gaudi-based monitoring algorithm:
#include "Event/ODIN.h"
LHCb::ODIN* odin=get<LHCb::ODIN>(LHCb::ODINLocation::Default);
double triggerType = odin->triggerType() ;
You may also need to add to the options file:
EventClockSvc.EventTimeDecoder="OdinTimeDecoder";

The trigger types are:

3 periodic trigger
? calibration trigger

Monitoring algorithms currently work in progress

N.B. if they are mentioned in brackets it is not yet clear if this belongs to the scope of the online monitoring or to other parts of the project but are listed here as well for completeness.

aim people involved brief description
Time-alignment, etc Gareth uses the special "calibration trigger" sent by the ODIN. These events are treated special during data-taking. Checks involve e.g. switching on the four corner pixels per HPD, flash a laser, record dark-count data
PID monitor Guy, Raluca monitor pion / kaon (mis-) ID rates using D* -> D pi decays
dark-count, ion feedback, etc. Nick clustering of hits, etc for ion-feedback, micro-discharge measurements, etc
(HPD calibration) Sean optimise read-out of HPDs
online refractive index Claus online measurement of the (change of the) refractive index
(mirror alignment) Antonis monitor the alignment of the RICH mirrors
offline refractive index Anatoly offline determination and monitoring of the refractive index

Suggested monitoring algorithms

Monitoring published histograms online

Using the Presenter-Prototype ("HPDMonitor")

This tool (used during the September 2006 TestBeam and in the SSB2) subscribes to published histograms and displays them using a graphical interface. The monitor is based on ROOT only and should thus run on any machine for which DIM and ROOT are available. It is available from the central CVS software repsository via getpack Online/HPDMonitor The current tag is v1r4 (please refer to the release notes and compare to the head revision)

The screen-shot shows the monitor and illustrate its interface Presenter1.jpg

To run the monitor:

  • make sure that ROOT and DIM libraries area available and accessible via the corresponding environment variables This is done automatically when using cmt by sourcing the setup.(c)sh in the cmt area of the package.
  • set the environment variable DIM_DNS_NODE to point to the host with the relevant DIM DNS service.
  • execute GaudiMonitor.exe in the bin directory
  • press connect to connect to the DIM DNS server
  • select the histograms you wish to monitor from the list in the tree-like structure
  • press select to subscribe to the selected histograms, the main canvas will be partitioned accordingly to fit all selected histograms.
  • press start or pause to start/pause updating the histograms
  • use the print button to create both an .eps and a .jpg of the current canvas, all selected histograms are also saved into a .root file with a time-stamp
  • the detail button opens an extra canvas which displays the histogram the mouse currently hovers over
  • use the write button to create the file SelectedDimServices.txt in the current working directory which contains a list of the selected DIM service names (histograms only at the moment)
  • use the read button to read the file SelectedDimServices.txt from the current working directory and automatically select the histograms listed there.

Note:

  • an alias, HPDMonitor is set up by the setup.sh script (so source /group/rich/sw/scripts/Online_v3r3_Setup.sh; HPDMonitor should be enough to display the monitoring windows, if there are no setup problems)
  • the size of the monitoring display window can be changed with command line arguments, e.g.: HPDMonitor -width 1280 -height 1024

How to use the write and read button:

When the write button is pressed, the file SelectedDimServices.txt is created in the current working directory. It contains a list of DIM services for the currently selected histograms, e.g.

H2D/UKerzel/ComMon/R2_Left_Col0_Nr0_525014-XYHitPosition
H2D/UKerzel/ComMon/R2_Left_Col0_Nr10_527008-XYHitPosition
where the individual elements are
H2D specifies that a 2D histogram is selected
UKerzel specifies the UTGID of the monitoring algorithm publishing the histogram
ComMon name or alias of the monitoring algorithm publishing the histogram
the last part is then the name of the histogram

When the read button is pressed, the monitor attempts to read back this file from the current working directory, connects to the DIM DNS server and automatically selects the histograms specified in the file if they are found in the list of available services obtained from the DNS server. N.B. if something changes in the list of available services (such as the UTGID or the algorithm name/alias) the histogram will not be found automatically. The file SelectedDimServices.txt then needs to be recreated or edited.

Using the official LHCb Presenter

A first version of the official Presenter (currently v0r2) is provided by the Histogram & Monitoring-group in the control room. To invoke it:
  • login to an appropriate machine, e.g. an HLT farmnode (for example hlte0401)
  • invoke . /group/online/presenter/presenter.sh
which then starts the official Presenter. You may need to edit the script and set the environment variable DIM_DNS_NODE to the appropriate value

How to test the software locally

Install the necessary packages (via getpack)in your cmtuser area. First setup the online environment: setenvOnline vNrM (at present, v3r3) which will bring you to the area ~/cmtuser/Online_vMrN In this directory, get the packages from the central CVS repository. At the moment, use the head revisions of
  • getpack Online/HPDMonitor head
  • getpack Rich/RichOnlineMonitors head
  • getpack Rich/RichMonitoringTools head
  • getpack Rich/RichMonitoringSys head
Then source the setup.(c)sh in Rich/RichMonitoringSys/vArB/cmt/ and build the packages RichMonitoringTools and RichOnlineMonitors The Presenter can be build separately, see the above section for more details.

Using the online environment

This setup uses the online software environment to test the monitoring algorithms locally including the interaction with DIM.
  • setup a recent release of the online environment, e.g. setenvOnline v3r3
  • edit the cmt project file of the online environment (found in $User_release_area/Online_vMrN/cmt/project.cmt) and add the line use LBCOM LBCOM_vXrY (the appropiate version number for the version of the online environment you are using)
  • get a local version of Online/GaudiOnline with the appropriate version, e.g. getpack Online/GaudiOnline vArB (the appropriate version to use with the version of OnlineSys you are using) and compile it. This provides Gaudi.exe and libGaudiOnline.so in the InstallArea. N.B some issues are observed with GaudiOnline. In case of problems, try to use a private version of the head revision of Online/GaudiOnline
  • source the setup.(c)sh in $User_release_area/Rich/MonitoringSys/.../cmt/. Depending on the setup, you need to edit the requirements file in this package und uncomment the setups for CLHEP and RichDAQ
  • start a DIM DNS: $DIMROOT/slc4_ia32_gcc34/DNS.exe on a suitable host
  • set the environment variable DIM_DNS_NODE to point to the host with the DIM DNS
  • you can monitor the available DIM services starting the DID (Dim Information Display): $DIMROOTslc4_ia32_gcc34/did.exe& (N.B. in case this doesn't work due to some X problem, the older version is still available at: /afs/cern.ch/lhcb/online/control/DIM/v16r5/slc4_ia32_gcc345/bin/did &)

  • start the Gaudi process running the monitoring algorithms via
     $User_release_area/Online_vMrN/InstallArea/slc4_ia32_gcc34/bin/Gaudi.exe   \
     $User_release_area/Online_vMrN/InstallArea/slc4_ia32_gcc34/lib/libGaudiOnline.so GaudiOnline    \
      -runable=LHCb::OnlineRunable    \
      -options=$User_release_area/Online_vMrN/Rich/RichMonitoringSys/vXrY/options/TestOnlineMonitor.opts      \
      -loop   \
      -auto
(N.B. all in one line, the \ indicates the line-break inserted here to make it more readable)

Using the offline environment

The monitoring algorithms are standard Gaudi algorithms and should thus run with your preferred Gaudi application such as Brunel.exe or DaVinci.exe. No interaction with DIM is possible in this mode, however, histograms created via plotND() will still be filled.

RICH monitoring during LHCb data-taking

This paragraph summarises the necessary setups needed to run the RICH online monitoring when taking data using the global detector control.

N.B. This part is extremely new and has not yet been tested in a global commissioning exercise.

Setups

The software and options files are taken from the RICH area, i.e. /group/rich/sw/cmtuser. Therefore, extreme caution should be taken when working in this area as it is no longer exclusively used by the RICH group.

Scripts

The main script used by the global detector control FSM is RichDAQMon.sh in /group/rich/scripts.

The version of the RICH online monitoring used for the global data-taking is hard-coded in the script and has to be changed accordingly with each upgrade. It uses the script setup.vars in Rich/RichMonitoringSys/vXrY/cmt to setup the environment. This script is using setup.sh created by cmt config by executing ${CMTROOT}/mgr/cmt setup -sh -pack=RichMonitoringSys -version=v1r2 -path=/group/rich/sw/cmtuser/Online_v4r3/Rich -no_cleanup $* > N.B. This has to be done for each release of the online monitoring software and when switching between "normal" and "debug" versions.

Further information

LHCb online monitoring project

The web-pages of the LHCb online monitoring group are found here

The meetings of the group are available via Indico, an (incomplete) list is collected below:

Hardware and L0 IDs for Rich2 C side

see attached file (provided by Antonis)

Data format

The EDMS document 768873 summarises the data format sent by the UKL1 boards

DIM

The online monitoring uses DIM (Delphi / Distributed Information Management system) to publish information and interact with the services. Further information can be found on the DIM webpages. Jump directly to the C++ documentation

OnlineSys

The Online project is documented on these web pages

Publishing information

Information (histograms, counters, etc.) are published from the GaudiLHCb.Algorithm by calling declareInfo, the interface is defined by the IMonitorSvc class.

Details on monitoring farm (from Monica)

1. How much CPU power will the monitoring farm have, will each sub-detector get some dedicated fraction?

The CPU power will be initially that of 8 lxplus nodes (the new SLC4 type) (actually our nodes are even slightly faster). There will be no dedicated fraction initially, if we see "misuse" we can enforce CPU quotas, but we hope that will not be necessary. When we know the applications better, we can discuss some adequate load balancing. It is clear that given the Gaudi architecture more CPU power can only be used by running multiple instances of a job (like we do in the HLT).

2. What kind of triggers/ events are streamed to the monitoring farm? - I guess it gets mainly min-bias and the special calibration trigger sent in the large gap between the trains of bunches?

The monitoring farm will run on HLT accepted events. Calibration events will be processed in a dedicated part of the EFF (calibration farm) and will not be written to storage. The only known user so far is the calorimeter.

3.  Is it also possible to 'subscribe' to some selected HLT triggers, e.g. the output of the HLT D* trigger can be selected as input to a specific monitoring process on the monitoring farm?

In principle all triggers which have passed the HLT - and only those! - are available. The jobs on the monitoring farm will subscribe to one or more types and be fed. Obviously you cannot expect to be able to analyse all triggers.

4. What fraction of events are (roughly) sent to the monitoring farm? How is this done, do the specific monitoring processes sort of 'request' the next event, i.e. is a possible scenario that we have a collection of "fast" monitoring algorithms  (e.g. hits in the photo-detectors) and "slow(er)" ones (e.g. somer higher level analysis)?

Each node in the MF will receive a fraction of the accepted events, according to needs. For most monitoring activities, ~100 Hz is already a large number of events for filling histograms. Essentially whenever the a process is idle it will be fed with the next available trigger of the correct type. If the rate of what you subscribe to is too high, you will miss some, if is too low, your process will idle.

Clean up the event-builder

To make sure all tasks are ended, etc. the following command sudo /group/online/scripts/cleaneb kills all processes related to the event-builder

Using the FMC log viewer

The various processes (can) send their messages to a central log server. To connect to the output, execute /opt/FMC/bin/logViewer A set of command line arguments is displayed using -h

Misc

Upgrade to a new release of the Online software environment

This paragraph summarises the steps needed to upgrade the online (monitoring) software environment to a new version of the Online release. Several packages are needed and multiple changes have to be made in the options files.

Needed software packages

  • set-up the environment for the appropriate release of the online software, e.g. setenvOnline v4r3
  • get the packages Rich/RichMonitoringSys, Rich/RichMonitoringTools, Rich/OnlineMonitors with the appropriate tags.
  • get the packages Online/GaudiOnline and Online/OnlineTasks with the appropriate tags
  • get the package Online/HPDMonitor with the appropriate tag if you want to run the prototype of the presenter

Changes to the options files

package options file change comment
Online/OnlineTasks MEPInit.opts -s=70000 -b=15  
  MDFWriterLite.opts Writer.Connection = "file:///data/rich/rich";  
    Writer.MaxFileSizeKB = 300000;  
    EventSelector.REQ1 = ... , UserType=VIP, ...  
  MEPRxSvc.opts Runable.MEPBuffers = 2; build 2 events at a time
    Runable.MEPBufSize = 10000000;  
    Runable.sockBuf = 4000000;  
    #include "$ONLINETASKSROOT/options/EBRich2_$UTGID_HOST.opts"  
  ReadMBM.opts #include "$GAUDIONLINEROOT/options/OnlineEnvironment.opts"  
  EBSetup.opts Runable.IPNameOdin = "192.169.5.4" IP of ODIN board used (for throttling)
  EBRich2.opts Runable.rxIPAddr = "$RXIPADDR"; comment out Runable.IPProtoIn
    "192.169.1.1", "UKL1_1", "",  
    "192.169.1.4", "UKL1_4", "",  
    "192.169.1.5", "UKL1_5", "",  
    "192.169.1.6", "UKL1_6", "",  
    "192.169.1.8", "UKL1_8", "",  
    "192.169.1.9", "UKL1_9", "",  
    "192.169.1.11", "UKL1_11", "",  
    "192.169.1.12", "UKL1_12", "",  
    "192.169.5.4", "ODIN", ""  
Rich/RichMonitoringSys requirements use CLHEP v* LCG_Interfaces  
    use RichDAQ v* Rich  

scripts

The following scripts in the group area /group/rich/scripts/ need to be adapted as well.

N.B. the latest version (as of 13.Dec. 2007) have a _v4r3 suffix and are adapted to v4r3 of the Online software

script change comment
hltrx.sh change path to setup.sh
runCamera.sh change path to Camera
rich_login.sh change path / version numbers
RichDAQMon.sh change path used by global detector control

Create the script setup.vars in the cmt area of Rich/RichMonitoringSys


Main.ukerzel - 17 Mar 2007

Topic attachments
I Attachment History Action Size Date Who Comment
JPEGjpg Presenter1.jpg r1 manage 436.0 K 2007-04-20 - 17:24 UnknownUser  
Texttxt Rich2_CSide_HardID_L0ID.txt r1 manage 1.6 K 2007-04-26 - 11:45 UnknownUser Rich2 C side, Hardware and L0 IDs
PNGpng RichCornerPixels.png r1 manage 31.6 K 2007-08-28 - 16:08 UnknownUser Screen shot of the RichCornerPixels output
Edit | Attach | Watch | Print version | History: r64 < r63 < r62 < r61 < r60 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r62 - 2008-04-07 - UlrichKerzel
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    LHCb/RichOperations All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2022 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback