Getting an Integrated Luminosity of a CAF Sample

by Greg Landsberg - Last update on 25-Nov-2005

Introduction

Depending on the version of CAF data you are using, getting luminosity for a sample may require a few tricks. In general, what you need is as follows:

The name of the CAF stream or a SAM definition that produced it;
The names of the triggers you are using and the corresponding run ranges;
List of files you are going to process.

Unfortunately, not all the CAF samples are stored in SAM, so for those that do not, you would need to rely on the parent TMB sample in order to get the luminosity.

Getting file parentage

In order to do so, one needs to use a clued0 script by Marco Verzocchi. The documentation is a bit sketchy and can be found in two places: Luminosity Group Web Page or a DØ News Message.

The syntax on clued0 is as follows:

% setup sam
%/home/mverzocc/scripts/genLBNtables -format TMB|CAF -skim -pass [-filelist -type LM|DB ]

Note that in the best traditions of DØ, the script is updated much more often than the documentation, so you can always find what are the latest switches and allowed values of the qualifiers simply by typing:

%/home/mverzocc/scripts/genLBNtables -help

You need to know the skim name and the data pass name (from the CAF Web page). Optionally, you can give the list of data files you are using, but this will only work if your CAF stream is in SAM. You can always leave this parameter out, which would simply create the parentage fro the the entire stream. Note that -format CAF qualifier won't work, if your CAF stream is not in SAM.

As a example, let's create the parentage for a 2EMhighpt stream for p17pass1 (unfixed) data. This CAF stream is not in SAM, so we will have to used -format TMB qualifier:

% /home/mverzocc/scripts/genLBNtables -format TMB -skim 2EMhighpt -pass p17pass1 > /dev/null

The result of running the code will be a subdirectory with the name given by the name of the stream (2EMhighpt) with a list of files containing parentage information, one file per original TMB file. The code also outputs a list of luminosity blocks, which is very long, so it's a good idea to redirect the output to /dev/null or a file. Parentage file names should look something like that:

CSskim-2EMhighpt-20050817-183228-1188087.raw_p17.03.03.parentage
CSskim-2EMhighpt-20050817-183331-1188087.raw_p17.03.03.parentage
CSskim-2EMhighpt-20050817-183420-1188087.raw_p17.03.03.parentage
CSskim-2EMhighpt-20050817-183519-1188087.raw_p17.03.03.parentage
CSskim-2EMhighpt-20050817-183636-1188087.raw_p17.03.03.parentage
CSskim-2EMhighpt-20050817-183726-1188087.raw_p17.03.03.parentage
CSskim-2EMhighpt-20050817-183815-1188087.raw_p17.03.03.parentage
...

Trigger Names and Run Range

The next step is to get the names of the L3 triggers you are interested in and the corresponding run ranges. Typically, change in the major version number of the trigger menu implies changes in the trigger name, while minor version updates don't change the names of the triggers. Information about the trigger menus can be found on the Triggermeister Web Page.

As an example let's determine the names of the triggers and the run range for a diEM and single EM triggers, which can be efficiently used for selection of Z(ee) events. The entire data set currently spans several major version of trigger menu: v11, v12, v13, and v14.

Let's start with v14 - the current (as of 11/25/05) version of the menu. On the triggermeister Web page, pick a particular version of the trigger menu, e.g. global_CMT-14.80 (this link is being redirected to Trigger Database Front Page). Click on the link and wait until the entire trigger table is downloaded in the browser (may take a while). Scroll down the list and look for E1 family of triggers (those are unprescaled to highest luminosities). One can use a trigger E1_2L20_L25 (L1: Calorimeter EM objects with E_T>12 GeV. Veto on cal_unsuppressed condition. L2: requires the sum of the two highest EM towers to be >= 15 GeV. L3: The trigger bit set to true if two electrons are found with Et>20 GeV satisfying loose requirements and also requires one |eta|<3.6 electron with E_T>25 GeV with loose requirements) or a slightly lower-threshold E1_2SH10_SH15 trigger, which uses loose cuts on the EM shower shape (L1: Calorimeter EM objects with E_T>12 GeV. Veto on cal_unsuppressed condition. L2: requires the sum of the two highest EM towers to be >= 15 GeV. L3: The trigger bit set to true if two electrons are found with Et>10 GeV satisfying loose shower shape requirements also requires one |eta|<3.6 electron with E_T>15 GeV with loose shower shape requirements). Note that the version of the trigger (/2) should not be included in the name. It's a good idea to check that these triggers have been present from the very beginning of the v14 trigger list, by checking global_CMT-14.00 (this link is being redirected to Trigger Database Front Page) menu. Indeed, both triggers are there as well. As far as single EM triggers are concerned, one could use E1_ISHT22 (this link is being redirected to Trigger Database Front Page) or E1_SHT25 (this link is being redirected to Trigger Database Front Page) triggers, although their threshold gets close to the pT range of interest, and they also have quite tight shower shape and isolation (in the case of the first trigger) cuts. Note that the E2, E3, E4, E5 suites of triggers are generally prescaled at high luminosities. We can estimate the luminosity for, e.g., E4_2L20_L25 (this link is being redirected to Trigger Database Front Page) trigger to prove this.

You now need the list of runs for which this particular trigger was set. Click on the Runs using this TriggerList link next to the global_CMT-14.00 trigger menu. You will get all the runs for which this version of the trigger was run. The lowest-numbered run in this list (207217) is the first run in which the trigger was run. Then go to a similar link for the latest global_CMT-14.xx menu present. (As of 11/25/05 it was global_CMT-14.80.) Find the highest-numbered run for which the trigger was run (currently, 211921). It's quite safe to use it as the upper boundary as the data from this run is probably being reconstructed just now and thus it's not in your sample yet.

Repeat the same exercise for other trigger versions. For v13 we will be using E1_2L20 (this link is being redirected to Trigger Database Front Page) and E1_2SH10 (this link is being redirected to Trigger Database Front Page) diEM triggers and E1_SHT22 (this link is being redirected to Trigger Database Front Page) single EM trigger. The corresponding run range is 194567 to 209104. Note that E1_2SH10 trigger was not present in the early v13 menus, so we will be using E1_2SH8 (this link is being redirected to Trigger Database Front Page) trigger for menus 13.03-13.11 (runs 194567 to 195838). One can see that the change occurred in version 13.20 by looking at the commentaries on changes listed below trigger versions. Note that there is significant overlap between the run ranges for v13 and v14 triggers. Essentially, v13.90 was run intertwined with v14.00-14.31 menus. Thus, one needs to be a bit careful in selecting the run range. It turns out that in the overlap region, runs 207217-209104 the following set of runs correspond to various trigger versions:

v13: <= 207216, 207229-207257, 207287-207342, 207350-207680, 207749-208145, 208246, 208444-208500,209102-209104;
v14: 207217-207222, 207279, 207343-207345, 207719-207740, 208168-208206, 208276-208434, 208512-209099, >=209147.

For v12 we can use E1_2L20 (this link is being redirected to Trigger Database Front Page) and E1_2SH8 (this link is being redirected to Trigger Database Front Page) diEM triggers and E1_SHT20 (this link is being redirected to Trigger Database Front Page) single EM trigger in the run range from 179069 to 194597. Note that there is an overlap in the run range with v13 as the menu was switched back and force between runs 194567 and 194577. This sometimes happens if the new trigger version is unstable, but wouldn't matter for our luminosity calculations, as two of the three types of triggers are common between v12 and v13.03. If we need to estimate the luminosity of the single EM trigger, one would have to be specific about the runs in the overlapping region for which each version was run, i.e. E1_SHT20: 194595-194597 (v12) and E1_SHT22: 194567-194577 (v13). Finally, for v11 and below the triggers to be used are 2EM_HI (this link is being redirected to Trigger Database Front Page) and EM_HI_SH (this link is being redirected to Trigger Database Front Page) (runs 141737 to 178721).

Summarizing all of these, we have the following triggers and run range for, say, a single EM trigger:

EM_HI_SH 141737 178721 // v3-11
E1_SHT20 179069 194566 // v12
E1_SHT20 194595 194597 // v12
E1_SHT22 194567 194577 // v13
E1_SHT22 194662 207216 // v13
E1_SHT22 207229 207257 // v13
E1_SHT22 207287 207342 // v13
E1_SHT22 207350 207680 // v13
E1_SHT22 207749 208145 // v13
E1_SHT22 208246 208246 // v13
E1_SHT22 208444 208500 // v13
E1_SHT22 209102 209104 // v13
E1_ISHT22 207217 207222 // v14
E1_ISHT22 207279 207279 // v14
E1_ISHT22 207343 207345 // v14
E1_ISHT22 207719 207740 // v14
E1_ISHT22 208168 208206 // v14
E1_ISHT22 208276 208434 // v14
E1_ISHT22 208512 209099 // v14
E1_ISHT22 209147 211921 // v14

One then put these ranges in the runrangelist file to be used for luminosity calculations.

List of files

This is simply the list of CAF files you plan to run on. It may not be identical to the entire skim. Typically it would look something like that:

CAF-V1-CSskim-2EMhighpt-20050526-174626-890101.raw_p17.03.03.root
CAF-V1-CSskim-2EMhighpt-20050603-054407-922287.raw_p17.03.03.root
...

Note that if your CAF files are not in SAM, you will need to change the names of files to correspond to the parentage files produced earlier. Comparing the names of parentage files with the above list, it's clear that you want to delete "CAF-V1-" and ".root" from the list of filenames in order for the luminosity code to run correctly. Your final file list would look like:

CSskim-2EMhighpt-20050526-174626-890101.raw_p17.03.03
CSskim-2EMhighpt-20050603-054407-922287.raw_p17.03.03

Getting the luminosity

Now we have all the necessary components to get the luminosity. This is done via the runrange_luminosity script documented on the Luminosity Group Web page. If you have a good run list or a bad run/luminosity block list, put it in the directory you are going to run in the files with the names: goodRunsList, badRunsList, badLBNList.

Syntax:

% setup d0_config
% runrange_luminosity

You can now go and get some lunch or perhaps a dinner, as it takes a while to run over a typical skim...

The result of your run will be the list of delivered and recorded luminosity corresponding to the triggers you chose, as well as a list of bad luminosity blocks, which you should throw away from the analysis. Typical output would contain several blocks, which look like that:

delivered luminosity for runs 141737-178721 is : 88.2286 pb^-1
processed 94131 lbns, of which 93410 were good

recorded luminosity for runs 141737-178721 and trigger EM_HI_SH is : 77.211 pb^-1 L3 accepts = 1.65497e+07
fraction lost was 0.124876
processed 94131 lbns, of which 92249 were good

recorded luminosity for runs 141737-178721 and trigger EM_HI_SH with bad lbn list is : 77.211 pb^-1 L3 accepts = 1.65497e+07
fraction lost was 0
processed 94131 lbns, of which 92249 were good

The last set of numbers give luminosity for EM_HI_SH trigger after bad LBN's are removed from your data sample.