Difference: DQMonitoring (1 vs. 6)

Revision 62018-09-23 - MarcoCattaneo

Line: 1 to 1
Changed:
<
<
META TOPICPARENT name="DataQuality"
>
>
META TOPICPARENT name="LHCbInternal.DataQuality"
 

LHCb Data Quality Monitoring histograms

The DQ pages have moved to https://lbtwiki.cern.ch/bin/view/Computing/DataQuality.

Revision 52008-09-25 - unknown

Line: 1 to 1
 
META TOPICPARENT name="DataQuality"

LHCb Data Quality Monitoring histograms

Changed:
<
<

Monitoring Farm

Last update: Jul 7 2008.

There are 96 bits written by the HLT into the data which will be used to determine which events go to which task in the monitoring farm (MF). The last 32 are for internal handling in the MF. Clients of these bits will have to provide

  1. The task to be run in the MF.
  2. The code to be run in the HLT that sets this bit. The trigger will not do that for you.
These tasks are under the responsibility of the subdetectors. They are the input for the understanding of the individual subdetectors.

About 50 Hz will be reconstructed using Brunel. See below for details. In an ideal world, one would run the reconstruction on all jobs and then distribute the output data to further monitoring jobs. This implies work. In the meantime, the safest is to run the same Brunel as offline, producing the same histograms. Fine tuning can be done later.

Histograms will be annalysed every 10 minutes using the OMALib histogram analyser package.

Brunel

Last update: Jun 30 2008.

Brunel is used as a monitoring tool both online (in the MF farm) and offline when the data is reconstructed. All groups should define a set of control histograms which can be looked at by the histogram analyser.

Offline there will be a file of 60k events produced every 30 seconds. This will also be the rate at which the reconstruction will run. Therefore everything must be automated, in the same spirit as what is done online.

The OMAlib histogram analyser package can be used offline as well as online. The input would be histogram files rather than histograms from the monitoring farm. A file contains about the same number of events as what will be reconstructed online in a cycle (20 minutes). There is thus no gain in statistics in a file. It's only be merging files that we gain in statistics. It then becomes interesting to have profiles per time unit. A file would be the simplest to use.

Of course reprocessings and strippings would have to be monitored as well.

Histograms in Brunel

Below is a list of the available histograms in Brunel. The will need to be defined in the database used by OMAlib.

Velo

Last update 18/8/08.

Two new packages added to be the next release of Brunel. Produce a lot of plots. Maybe size is an issue.

ST

Nothing yet.

OT

Nothing yet.

RICH

Last update 18/8/08.

There are monitoring histograms produced by default, but as part of the checking sequence. Will be fixed for the next release.

Calo

Last update 18/8/08.

The Calo monitoring sequence has been switched on in Brunel (tag pkoppenb_20080818) and produces many histograms.

Muon

Last update 18/8/08.

There are checking histograms. A preliminary version without MC exists but is not yet released.

BUG: Uncommenting Muon in the monitoring sequence call Muon checking.

Tracking

Last update 21/8/08.

There is a package Tr/TrackMonitors. Algorithms need to be included in the monitoring sequence. Stephie and Woter are investigating.

L0 & HLT

Is there any need? Trigger is monitored by TisTosTobbing, which requires candidates, i.e. the stripping.

Size

Last update 18/8/08.

With velo and Calo switched on the monitoring size is now 3.3 MB.

The rule of thumb is that for every MB of histograms in Brunel per file gets 300 GB per year. (Assuming 10^7 second per year and 30 s per file).

>
>
The DQ pages have moved to https://lbtwiki.cern.ch/bin/view/Computing/DataQuality.
  -- PatrickKoppenburg - 18 Aug 2008

Revision 42008-09-17 - unknown

Line: 1 to 1
 
META TOPICPARENT name="DataQuality"

LHCb Data Quality Monitoring histograms

Line: 25 to 25
  Offline there will be a file of 60k events produced every 30 seconds. This will also be the rate at which the reconstruction will run. Therefore everything must be automated, in the same spirit as what is done online.
Changed:
<
<
The [http://isscvs.cern.ch/cgi-bin/cvsweb.cgi/Online/OMAlib/src/?cvsroot=lhcb][OMAlib]] histogram analyser package can be used offline as well as online. The input would be histogram files rather than histograms from the monitoring farm. A file contains about the same number of events as what will be reconstructed online in a cycle (20 minutes). There is thus no gain in statistics in a file. It's only be merging files that we gain in statistics. It then becomes intersting to have profiles per time unit. A file would be the simplest to use.
>
>
The OMAlib histogram analyser package can be used offline as well as online. The input would be histogram files rather than histograms from the monitoring farm. A file contains about the same number of events as what will be reconstructed online in a cycle (20 minutes). There is thus no gain in statistics in a file. It's only be merging files that we gain in statistics. It then becomes interesting to have profiles per time unit. A file would be the simplest to use.
  Of course reprocessings and strippings would have to be monitored as well.

Revision 32008-08-22 - unknown

Line: 1 to 1
 
META TOPICPARENT name="DataQuality"

LHCb Data Quality Monitoring histograms

Changed:
<
<

Monitoring Farm tasks

What's the status?
>
>

Monitoring Farm

Last update: Jul 7 2008.

There are 96 bits written by the HLT into the data which will be used to determine which events go to which task in the monitoring farm (MF). The last 32 are for internal handling in the MF. Clients of these bits will have to provide

  1. The task to be run in the MF.
  2. The code to be run in the HLT that sets this bit. The trigger will not do that for you.
These tasks are under the responsibility of the subdetectors. They are the input for the understanding of the individual subdetectors.

About 50 Hz will be reconstructed using Brunel. See below for details. In an ideal world, one would run the reconstruction on all jobs and then distribute the output data to further monitoring jobs. This implies work. In the meantime, the safest is to run the same Brunel as offline, producing the same histograms. Fine tuning can be done later.

Histograms will be annalysed every 10 minutes using the OMALib histogram analyser package.

Brunel

Last update: Jun 30 2008.
 
Deleted:
<
<

Brunel Monitoring

 Brunel is used as a monitoring tool both online (in the MF farm) and offline when the data is reconstructed. All groups should define a set of control histograms which can be looked at by the histogram analyser.
Added:
>
>
Offline there will be a file of 60k events produced every 30 seconds. This will also be the rate at which the reconstruction will run. Therefore everything must be automated, in the same spirit as what is done online.

The [http://isscvs.cern.ch/cgi-bin/cvsweb.cgi/Online/OMAlib/src/?cvsroot=lhcb][OMAlib]] histogram analyser package can be used offline as well as online. The input would be histogram files rather than histograms from the monitoring farm. A file contains about the same number of events as what will be reconstructed online in a cycle (20 minutes). There is thus no gain in statistics in a file. It's only be merging files that we gain in statistics. It then becomes intersting to have profiles per time unit. A file would be the simplest to use.

Of course reprocessings and strippings would have to be monitored as well.

Histograms in Brunel

Below is a list of the available histograms in Brunel. The will need to be defined in the database used by OMAlib.
 

Velo

Last update 18/8/08.

Revision 22008-08-21 - unknown

Line: 1 to 1
 
META TOPICPARENT name="DataQuality"

LHCb Data Quality Monitoring histograms

Line: 40 to 40
 BUG: Uncommenting Muon in the monitoring sequence call Muon checking.

Tracking

Changed:
<
<
Nothing yet.
>
>
Last update 21/8/08.
 
Changed:
<
<

HLT

Nothing yet.
>
>
There is a package Tr/TrackMonitors. Algorithms need to be included in the monitoring sequence. Stephie and Woter are investigating.

L0 & HLT

Is there any need? Trigger is monitored by TisTosTobbing, which requires candidates, i.e. the stripping.
 

Size

Last update 18/8/08.

Revision 12008-08-18 - unknown

Line: 1 to 1
Added:
>
>
META TOPICPARENT name="DataQuality"

LHCb Data Quality Monitoring histograms

Monitoring Farm tasks

What's the status?

Brunel Monitoring

Brunel is used as a monitoring tool both online (in the MF farm) and offline when the data is reconstructed. All groups should define a set of control histograms which can be looked at by the histogram analyser.

Velo

Last update 18/8/08.

Two new packages added to be the next release of Brunel. Produce a lot of plots. Maybe size is an issue.

ST

Nothing yet.

OT

Nothing yet.

RICH

Last update 18/8/08.

There are monitoring histograms produced by default, but as part of the checking sequence. Will be fixed for the next release.

Calo

Last update 18/8/08.

The Calo monitoring sequence has been switched on in Brunel (tag pkoppenb_20080818) and produces many histograms.

Muon

Last update 18/8/08.

There are checking histograms. A preliminary version without MC exists but is not yet released.

BUG: Uncommenting Muon in the monitoring sequence call Muon checking.

Tracking

Nothing yet.

HLT

Nothing yet.

Size

Last update 18/8/08.

With velo and Calo switched on the monitoring size is now 3.3 MB.

The rule of thumb is that for every MB of histograms in Brunel per file gets 300 GB per year. (Assuming 10^7 second per year and 30 s per file).

-- PatrickKoppenburg - 18 Aug 2008

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