lm_access package

Notes:

If you get errors about missing libraries in running lm_access, setup t05 or p17. Our gcc compiler changed.

The versions in ~schellma are being removed because they cause more problems than they solve, since we have so many OS compiler versions.

Useful commands:

runrange_luminosity: get the luminosity for a list of run ranges

dumpLBN <LBN> <TRIGGER>: dump the information for a given LBN and trigger

dumpstage3 <LBN> : dump the entire contents of a stage3 file - if your trigger is not in this file, it was probably not live for that LBN

Instructions:

Getting the package from CVS and the package compilation
Classes
Use runrange_luminosity as an example
Instantaneous luminosity and proton and anti-proton halos

Introduction

 The lm_access package is a tool for accessing luminosity information in physics analysis of the DØ data.

There is a framework interface called lm_access_pkg which allows control of lm_access via RCP's.

How the lum data are stored:


The smallest unit of time in which the luminosity is provided is luminosity block. The block is uniquely identified by its luminosity block number (LBN) and under normal circumstances its typical length is about 60 seconds (for detail explanation look at DØ note 3971). A status (based on luminosity data acquisition status, DØ note 3973) is assigned to each luminosity block. If nothing wrong happened during the time period associated with a given luminosity block, then the block status is good and corresponding flat file is created for that particular LBN in the stage3 directory /prj_root/500/com/offline/stage3 (accessible from cab and clued0).

Remote access: These files can be copied to remote locations but must be updated on a daily basis as the luminosity information is being constantly updated as new data come in. At the remote location, you must set the modify the lm_access or lm_access_pkg so that it points to the local equivalent of /prj_root/500/com/offline/stage3/

Instructions for remote setup are at remote_site.html

How to access the lum data:

Note, only data from good luminosity blocks can be properly normalized!

Luminosity information is provided only for triggers and lm_access package allows to find out three types of luminosity: triggered, recorded, and reconstructed. For an explanation of these terms look at DØ notes 3971, 3972, and ?reconstructed?. In case of triggered and recorded luminosity no checks are performed on release information. Triggered luminosity corresponds to the trigger luminosity at L1 level while recorded luminosity takes into account the event losses in DØ DAQ system and hence it corresponds to the luminosity in raw files.


    Most of the analysis requires reconstructed luminosity. This luminosity depends on the type of the data files (recoA, DST, or TMB) and also on the version of the reconstruction software. Also a check is performed on possible corruption of L3 information in the data (it concerns p10 root_tuples, p13.03 and earlier thumbnails).


    There is a possibility to switch off the checking of L3 trigger corruption (asking for luminosity type lm_access::ReconstructedDontCheckL3). However this option should be used with caution since there is no warranty that the particular trigger was not corrupted.


    Because the reconstructed luminosity per LBN can be different for various versions of the reconstruction code, the lm_access package groups the data (files) according the version of the code.

    To learn how to use the lm_access package in your data analysis,

The old example from 2002 is described at oldexample.


Last update August 24, 2005 , by H.S