Documentation Level 3 Muon Tools and Filters

July 2000 v1.2

Paul Balm

This documentation describes the muon-specific software, to be used by the level 3 trigger of the D0 experiment. Covered are:

• goals of the level 3 muon trigger
• software that is currently available, as well as what is being planned

1. Overview of Level 3 software

Essentially, the task of the Level 3 trigger is making decisions to pass events or to reject events. These decisions will be made by so-called filters. The filters that will be run, together with their parameter sets, will make up your trigger list: There may be a filter passing the event if it finds back-to-back muons, one that passes the event if it finds an isolated muon with high p_t or other muon signatures that indicate an interesting event. All filters together must on average finish running within 1 ms per Level 3 node. This is assuming a 1 kHz input rate into the Level 3 system.

The information needed by the filters to make their decisions, is provided by tools. A tool may for instance do tracking, and a filter decides whether the quality of the track is high enough to pass the event. Not all tools will have to be run every event. Trigger simulations should show what the allowed running time of these tools will be. Tools have a reference set, or refset, of adjustable parameters, to tune speed versus efficiency and resolution. Examples of parameters are the residual of a track, the name of the algorithm to use or whether matching with other detectors should be performed.

The ‘framework’ running on the Level 3 nodes is called ScriptRunner. Each event, ScriptRunner will run down the list of the filters. Each filter will call the tools it needs. It is likely that all filters for the muon system will need the muon unpacking tool, that converts raw data into a more legible format of hits with a drifttime and a position etc, as opposed to a wire-number and two time measurements. Of course the unpacking tool will only be executed once per event for a specific part of the detector. This "do not do the same thing more than once" functionality is built into all tools.

2. Muon software for the Level 3 trigger

1. Goals and improvements over the Level 2 trigger

The goal of the Level 3 Trigger is to filter events based on complete physics objects, such as muons, and the relationships between those objects, such as differences in rapidity. This is done through full reconstruction of the event.

By definition, Level 3 will improve in resolution and rejection efficiency over the Level 2 trigger. Concerning muon, improvements are made in processing the drift chamber information, muon scintillator information, calorimeter information, CFT and SMT information. The table below shows the improvements of level 3 over level 2 in these categories.

	Level 2	Level 3
Drift chambers	Uses first hit Uses wire centres in the FAMUS Uses first triplet	Fits all hits with drift distance Uses best fit Better momentum and track counting
Calorimeter	Not used	Track-like object. ETRACK, E33 for confirmation, isolation, independent z-vertex. dzvertex»20 cm
CFT	2 dimensional match	3 dimensional match dzvertex(CFT)» 1 cm (depends on isolation and luminosity)
Muon scintillators	Wide gate	Better time of flight calculation with dt»1-2 ns. Correlate times of A- and C-layer hits. Look at opposite side of detector. Fit for velocity. Separate muons from low b, cosmic.
SMT	perhaps STT information, when available	primary vertex dzvertex»0.1-0.2 cm, use of secondary vertex

1. Currently implemented tools

Currently implemented and tested are an unpacking tool and a local tracking tool.

The unpacking tool, L3TMuoUnpack, converts raw data into hits. The raw data of a hit consist of an index that indicates which detector element has been hit (which scintillator or wire), plus one or more times. Hits potentially have a position in the global coordinate system, plus a drift-distance or scintillator time.

The local tracking tool, L3TMuoLocal, tracks muons in the muon system only. The tracking tool calls the unpacking tool for hit information and uses the ‘offline’ algorithms in muo_segmentreco and muo_trackreco for tracking.

2. Foreseen tools

Apart from the tools we already have, one tool for every separate bit of information we need to make a trigger decision should be in this section. A couple of examples follow.

We do not plan to unpack the entire detector every event (as is done by the unpacking tool as it is currently implemented). That means we will not transform all raw muon data in the event into hits. Instead, we plan to have the Level 2 trigger or Level 1 tell us where it thinks there may be a track, and unpack only that chamber or (h,j) region. We will need a seed tool, following the convention we’ll call it L3TMuoSeed that will query in principle the Level 2 trigger and return the indices of chambers to unpack. There is a potential loss of efficiency here. Also, if unpacking is very fast, and converting (h,j) regions to indices slow, it may not even be faster to do it this way. Timing and efficiency studies will have to show this.

In Run I there was a software package called MTC, that tracks muons through the calorimeter. This will eventually be turned into a tool also, called L3TMuoCalTrack. A tool to calculate and check the validity of the time-of-flight of detected muons is also planned. This tool will make use of scintillator information.

Other jobs that have not been fitted in a tool yet are matching of central tracks with local muon tracks, and vertexing.

3. Filters

It should be noted that writing filters is the responsibility of the filters group, not the muon ID group. The muon ID group is responsible for the tools.

The only filters that currently exist are filters meant to test the tools in the online environment. There is a filter that passes the event if there are any hits found for testing the unpacking tool. Also, there is a filter that passes the event if there are any tracks found, for testing the local tracking tool.

Foreseen filters will include a single muon filter that passes the event if a p_t threshold is exceeded. A di-muon filter will be needed, that passes the event if two muon tracks originate from the same vertex, and have an acceptable invariant mass.

1. Level 3 Muon Roadmap

The Level 3 software is currently scheduled to be ready for roll-in January 31, 2001. Being ready for roll-in means having tested all necessary tools and filters and understanding the rates, efficiencies and rejection as a function of the algorithm parameters.

To structure the work that has to be done to get the Level 3 Muon software ready for roll-in, it is necessary to divide this work in different phases, that each tool should pass. It seems efficient, to first have a small set of basic tools pass all phases, and then start working on the more intricate tools.

The different phases should be:

• Basic implementation
• Timing and performance measurement
• Final implementation
• Study and report on rates, efficiencies and rejection as a function of algorithm parameters

Basic implementation is the first implementation without any tuning of the algorithms. The results of the timing and performance measurement should make clear where improvement is needed. These improvements are implemented in the third, final implementation phase. Finally a study of the behaviour of the algorithms the tool uses will be necessary, as well as a report on the results of the study.

The set of basic tools first to pass this trajectory is the unpacking tool and the local tracking tool, L3TMuoUnpack and L3TMuoLocal. Their basic implementation exists.

The current list of tools to have passed this trajectory by end of January 2001, is given in the section "Foreseen tools". This list will have to be extended by other high level tools, such as a tool for finding isolated muons, or two muons coming from one vertex. These will be decided upon after discussions at the biweekly muon ID meetings.

The official milestones, set by the management, are

• L2 inputs to L3 defined, April 2000

Designed but not fixed (to my knowledge). Implementation of the tool that obtains seed information for the unpacking tool must wait on this.

• Availability of raw data, generated by Monte Carlo, April 2000

Software has been released, currently being tested (May 15, 2000).

• Level 3 operational (one full chain), June 2000

This milestone has already been met.