This page, as an introduction, describes what a Level3 Trigger consists of. I'll assume that you know this background information when I answer the questions:

HOW DO I MAKE A LEVEL 3 TRIGGER?

I ONLY WANT TO CHANGE THE NAME!

Note - the filter code that is run can be found in the Level3Filters package in the offline CVS repository, viewable via the CodeBrowser.

Let's look at an example as we try to understand what is entered into the database for each piece of code that we use at Level3. If we want to trigger on muons, we want to use the L3MuonFilterModule , a Module written specifically to filter on muons. The source code can be found in the Level3Filters package:

Level3Filters/src/L3MuonFilterModule.cc

and the header file is:

Level3Filters/Level3Filters/L3MuonFilterModule.hh

We need to enter a Class into the database that contains the name of the Module, whether or not it is a Filter Module (L3 triggers can also have non-filter modules, like reconstruction modules) and the location of the header file. We also need to enter the talk-tos into this class that can be found in the Module code. Any talk-to that we want to be able to set in the tcl file run at level3 must be part of the Class associated with the Module in the database. These Classes have a Version field associated with them that allows us to keep the Classes current. We can make a new version of a Class if a talk-to in the underlying code changes - new talk-tos may be added, or talk-tos may have disappeared from the code. The version number allows us to keep track of which talk-tos we have access to and when the talk-tos changed. The first version of our L3MuonFilterModule will be called "L3MuonFilterModule_v1", where the database has entered the version number for us.

The Class is the basic building block from which we make Instances . The Instance is where we specify cut values. We simply choose the talk-tos we need in order to make the cuts that are required by each trigger. The instances, unlike the classes, do not have a separate version field, so we try to include a '_v#' when we declare the name of an instance, in case, for example, the 18GeV electron trigger needs a slight tweaking in lshr, eta, or another talk-to. That way if an instance needs a slight modification we can just rename it with a '_v(#+1)', which allows us to keep track of the history of the instance. An instance of the muon filter module that cuts on 4 GeV CMUP muons could be named "muonCMUP4_v1" where we have specified the version number when we declare the name of the instance, since a there isn't a separate field for versions of instances in the database.

Each trigger can be made up of as many instances as is necessary. For example, a trigger that relies on correlated objects may have two different instances of the L3TrackFilterModule followed by an instance of the L3TwoTrackFilterModule. There are many examples currently in the trigger database that show more than one instance per trigger. We have the ability to include Reconstruction Modules in the triggers in the same way as Filter Modules - they have an associated instance that specifies which talk-tos from the base class should be set. This gives us the flexibility to have path-dependent reconstruction.