-- MortenBadensoe - 09-May-2011

Tau Trigger Tracking for HLT

Macros used for matching trigger tracks with offline tracks in the tau-sector and measure efficiencies and unmatched (fake) rates.

Resume

The tau tracks found in the EventFilter and Level2 are matched to the tracks found with the offline tracking algoritms using the prunHLTTrks_EF/L2 program, which also fills a variety of histograms with a lot of different tracking variables used in the tau trigger tracking. The program outputs a root file, which then can be feed into the DifferencyPlots macro. It will create efficiency rates and unmatched (fake) rates between the chosen trigger and offline tracks, as well as various other histograms.

Main Program (prunHLTTrks_EF/L2)

The program uses either TTP ntuples or trig ntuples (TRIG_NTUP) from the runs on CAF to analyse the tracks from the tau candidates found in the EventFilter, Level2 and in the offline reconstruction. The different subscript EF or L2 refers to the trigger taus to loop over.

The starting point is a L1 tau candidate, and both a high level trigger (HLT) tau candidate and offline (OL) tau candidate have to be present in the given event. The HLT tau candidates have to pass the TAUNOCUT and the distance (dR) between the HLT tau candidate and the OL tau candidate has to be within 0.2. For both the HLT and OL tau candidate, certain variables are filled into histograms.

When the event contains both a HLT and OL tau candidate that are matched to each other within dR=0.2, the tracks from the OL tau are looped over. The OL tau tracks have to be within dR=0.25 with respect to the L1 direction to be considered. For all the OL tau tracks, various histograms are filled, e.g. TrkPt, TrkEta, TrkPhi etc. This is also true for the HLT tau tracks, but the HLT tau track have to be within dR=0.28 with respect to the L1 direction. The reason why the distance between the OL/HLT tau track and the L1 direction is different, is because of possible systematics due to edge effects.

For each of the OL tau tracks, the program loops over all the HLT tau tracks, in order to find the track that matches the OL tau track, if any. The distance between the HLT track and the OL track have to be within dR=0.1 in order for it to be considered. When there is a match, the various OL and HLT tau tracks are saved with a “matched” name, which will be used to determine the efficiencies with respect to HLT and OL Pt, eta and phi.

After all possible track matches, the unmatched tracks are found in order to determine the unmatched (fake) rates for Pt, eta and phi for the OL tau tracks.

The program creates a root-file with all the histograms. The root-file is called Dummy_EF/L2.root.

Usage

In order to run the macro, the following packages have to be checked out and installed: TTPNtuple, TTPAnalysis and TTPUtils. And to run the macro use the following command:

root -l -b -q setup.cxx prunHLTTrks.C++

The following parameters can be changed in the macro:

• Datafile(s) to use (ch.Add("/path/to/datafile/*"))
• Number of events to loop over (nEvents -- default=all)
• Minimum Space Points for the HLT track (nSpacePoints – default=-1)
• Maximum distance between L1 and HLT Track (max_dRL1HLT – default = 9999)
• Use both nSeedCaloTrack and WideTrack (both = true/false)

Macro for efficiency and unmatched rate plots

Using this simple root macro, various histograms are beautified and the efficiencies and unmatched rates are plotted. Also, the histograms are shown both for the HLT and the OL tau candidates and tracks.

For the efficiency, Eff, the definition is: Eff = passing cut flow & trigger / passing cut flow

And is given by the fraction: matched OL tracks/All OL tracks. The efficiency should be in the high 0.9 in the entire range for the pt, phi and eta.

The unmatched, or fake, rate is defined as the amount of HLT tracks that are not matched with any offline tracks, i.e. too many tracks found.

Fake rate = unmatched HLT tracks / all HLT tracks. The fake rate should be low in the entire range for the pt, phi and eta.

Usage

Run the macro using: root -l DifferencyPlots.C

The root macro takes the root-file from prunHLTTrks as input, defined as file1 in the macro. There is an option for creating a postscript file using the variable write_ps_file. Setting this to true a PS file called plots.ps with the various histograms and graphs will be created.

Results

The results shown here are obtained from the dataset: data11_7TeV.178044.JetTauEtMiss.AOD.f354_m765 which contains about 3 million events.

The tracks found from the tau candidates in the offline reconstruction are matched to the tracks found in the Level 2 and Event filter. The efficiencies and unmatched (fake) rates are found for the transverse momentum, eta and phi distributions. Only tracks that are within dR<0.25 for the offline and dR<0.28 for the L2/EF wrt. the L1 direction are considered. The HLT tau candidates has to have passed the TAUNOCUT trigger requirement.

L2:

For the Level 2 efficiency plots the nSeedCaloTracks container have been used for the offline tracks and the nTracks container has been used for the L2. For the unmatched (fake) rate plots, the nSeedCaloTracks+nSeedCaloWideTracks have been used for the offline tracks and the nTracks container for the L2.

The OL efficiencies are given by: eff = passing cut flow & trigger / passing cut flow The unmatched rates are given by: Fake rate = unmatched HLT tracks / all HLT tracks

shown picture of eff shown picture of fake rate -- using all spacepoints

In the particular dataset used, the number of Spacepoints (nPixelhits+nSCThits) for the L2 tracks can go as low as 4 in certain eta vs. phi regions due to faulty/defect models in the inner detector. As part of the study, it was found that if tracks with only 4 space points were included, the efficiencies only increased slightly, where as the unmatched rates were increased quite a bit.

shown picture of eff and fake rate --- using 5 or above SpacePoints

In general, the efficiencies are similar with the ones seen last year (see Peter Kadlecik's talk: https://indico.cern.ch/contributionDisplay.py?contribId=10&confId=107206 – It has to be noted that the plots shown in the link are using events with 1 primary vertex). The amount of unmatched tracks are quite a lot higher. The unmatched rates given the normal requirements, space points requirement (SP>=4) and space points (SP>=4)+dR(L1,L2)<0.2 are given below.

It is clear that it is possible reduce the amount of unmatched tracks quite a bit, without loosing to much efficiency. At this point only the SpacePoint>=5 requirement is the only one used.

Event Filter:

For the event filter efficiency plots the nSeedCaloTracks container have been used for both the offline and the event filter tracks. This is also the case for the unmatched (fake) rate plots. The algorithms used in the offline reconstruction and the EF is similar.

shown pictures of eff and fake

Compared with the results from last year (see Peter Kadlecik's talk: https://indico.cern.ch/contributionDisplay.py?contribId=10&confId=107206 – It has to be noted that the plots shown in the link are using events with 1 primary vertex), the efficiencies are a bit lower, but not too much. The unmatched tracks are also higher, so in order to see if it is possible to match these additional EF tracks, the unmatched rate plots have also been made using both the nSeedCaloTracks and nSeedCaloWideTracks for the OL tracks and nSeedCaloTracks for the EF. This way, the amount of unmatched tracks is lower, due to the fact that some tracks with end up in the nSeedCaloWideTracks container in the offline reconstruction, and hence result in a higher unmatched rate.

show pictures of fake rate -- using “all” OL track containers.

Using both the nSeedCaloTracks and the nSeedCaloWideTracks container for the OL tracks, it is seen that the unmatched rate is reduced between 0.01 and 0.04 depending on the distribution.

Old

The purpose of this program is to run a Partition automatically against a database, and return a webpage with various information about the Partition run. These information can then be compared with previous runs. Different options for the partition run can easily be specified in an options file. Furthermore, analysis against different reference files is possible after the partition run with a standalone program.

In the webpage the number of warnings, errors and fatals occurring during the run will be shown along with a list of them. Selected histograms generated after the Partition run will be shown both as histograms and as values only. These histograms cover the ChainAcceptance and Errors from Level 2 and EventFilter. Furthermore a comparison is made with a reference Partition run, where the ChainAcceptance, Errors and Timers for both Level 2 and EventFilter are being compared.

The two programs

• part_vs_DB.py
  • This runs the partition against a database and returns the webpage described above.
• modtest.py
  • Standalone analysis with new reference files.

Warnings, errors and fatals

After the partition run a tarball is generated with the log files from the whole run. The important ones are the L2PU and PT:EF. These files will be scanned, and warnings, errors and fatals will be extracted and stored. It is, however, possible to map out certain patterns, which is to be ignored when looking for warnings, errors and fatals in the files. The patterns can be written in the module read_tar_function. The number of ignored elements will be shown on the webpage as well.

If a core dump occurs, it will be stored separately and shown in the top of the generated webpage.

Histograms and tables

The analysis part uses the generated ROOT files and has modules for the analysis of both the run and comparison with a reference file. The main webpage is hardcoded into modtest.py so if new modules are added, they should be added to the page here.

Usage

For general information see HLTPartitionTesting.

The needed files are in:
/pcatr-srv1/home/aej/HLTPartitionAutoTester/

To run a partition against a database

part_vs_DB.py
The program is run by without arguments as these are all specified in the options file cfg.py. Each run is saved in a folder named after date and time of run. The path for the webpage is printed in the terminal.

cfg.py
All values in the option file has to be checked before running and have to be changed for runs with different menus or different reference files.

# Partition name
config['partname']='my_partition'

# The datafile
config['datafile'] = 'my_file.data'

#Histograms to compare with - give full path :
config['L2comphist']='my_L2_ref.root'
config['EFcomphist']='my_EF_ref.root'

As the path's to the histogram in the ROOT files change they must be specified for first run.

#Path to histograms in root file: 
config['cdL2']='Histogramming-L2-Segment-1-1-iss/L2PU-8191'
config['cdEF']='Histogramming-EF-Segment-1-1-iss/PT-1_EF-Segment-1-1_pcatr15_1'

#Root filename
config['L2name']='/Histogramming-L2-Segment-1-1-iss.root'
config['EFname']='/Histogramming-EF-Segment-1-1-iss.root'

To correct partition name and to correct some default values the following are needed. Entries can be added to config['changes'] for further changes which will then be included in the file given by config['xml-change'].
For more about post-processing see Post-processing

# Post-processor XML-changing file name (without .py) if any
config['xml-change'] = 'change_xml_vars'

# Syntax [['Class','attr',value],[....]]:
#config['changes'] = [[],[]]
config['changes'] = [['L2SVConfiguration','l2puTimeout_ms',15000]]

Lastly specifics for the database must be given

# DB entry to use 
config['hltPrescaleKey'] = 5
config['SuperMasterKey'] = 8

# DB connection information:
config['Server'] = 'devdb10'
config['Port'] = ''
config['User'] = 'atlas_trigger_myname'
config['Password'] = 'my_not_so_secret_pass'
config['Name'] = 'atlas_trigger_myname'
config['Alias'] = ''

Any non-default things to be changed for the run-test.py is being set by the user via the option file generated by: run-test.py -D > ,
where the is set by:
config['run-test-options'] = 'run-test-options.py'

For the first run The run-test option file has to be copied along with the other files or it can be created with python run-test.py -D <run-test-options-filename> and the name be specified in cfg.py.
If this is done option['save-run-logs'] = True should be set, to save logs for error analysis.

Files for partition access Before first run the files for partition access (authentication, dbaccess, dblookup and l2efhoptDB) has to be in the directory as well and the user need to have a partition to run on. For further info see HLTPartitionTesting.

l2eflhoptDB.py
Is a modified version of l2eflhopt.py for access to database (See HLTPartitionTesting). The partition name and the the version (ie. 15.4.0.2) has to be corrected in here for first run. This file is in the folder mentioned above.

To run simply against new reference files

modtest.py is called from part_vs_DB.py and does the histogram analysis but it can also be called alone to run against other reference files by: python modtest.py -b Each run is saved in a new folder with date and time as name. A webpage with the new references can be opened with the path printed in the terminal.

-- MortenBadensoe - 09-May-2011