The Level 3 triggers are programmable, to enable us to retain flexiblity.
Rebuilding an online executable can be a tricky and dangerous undertaking
so we want to avoid hard coding in parameters that someone might want to
change. The following episode describes the parameter types and the current
format.
From the Run-I experience, we know that these parameters fall into three
broad classes:
Unchanging Algorithmic parameters
Algorithmic parameters are the sort of thing that you will spend an
awful lot of time tuning for some given algorithm. You'll do studies, make
histograms, argue with people at ID meetings, panic about them when data
first comes in, do more studies, have more arguements, then set them and
threaten to throttle anyone who proposes to change them. These parameters
need to be highly dynamic during the tuning phase when running offline
and static during data collection. Since these parameters do not change
often, we do not want to spend time downloading them. Use rcp to
read these parameters in
Candidate selection parameters
Candidate selection parameters can change run by run, and even trigger
by trigger. We refer to these as reference set parameters. They also are
algorithmic parameters, but differ in that they are the sort of parameters
that are used to determine the valid list of candidates. To illustrate
the difference, let's use EM isolation as a simple example. How isolation
is defined would be a set of A. type parameters. We would seldom want them
to change since we want the definition to be stable. But the cut placed
on that definition would be a type B. parameter, depending on how much
rejection we need to get for a particular trigger for a particular luminosity.
Multiple refset parameters can be defined for each tool in a single trigger
list, as in the following example from Gustaaf: "At start of run, we will
create multiple instantiations of the tools with different sets of parameters
(we often use the example ele_tight, ele_loose, ele_escape as 3 instances
of the electron tool)." I imagine that parameters will move between these
catagories as you learn more about your algorithm.
Kinematic parameters
Kinematic Parameters. These parameters, like ET threshold, are passed
in via the trigger list to the filters. We need to make sure that the trigger
list is sane. Every valid tool has to have an entry in the tools file.
This defines the tool, its parameters, any defaults for those parameters
and a valid range for the parameters if applicable. Here is an example
tool definition in tools.dat:
**** L3TEleTool EMSEED (no default) TRACK (no default) isolation 0.1 0. 10. EMFR (no default) (no
range) likelihood (no default) (no range) key (no default) **** where: **** are delimiters between tool definitions.L3TEleTool is the name
of the tool EMSEED, and
TRACK are the strings that
correspond to the instance of those tools that L3TEleTool
will use (remember--tools can call other tools). Isolation is a parameter
that has a default cut and a [min,max] range. If the parameter is out of
that range, the parser will flag an error. If isolation is omitted from
the refset definition, the default will be used. key is the name of the
tool instance. The refset programming in the trigger list that corresponds
to this tool looks something like this:
EM_SEEDS L3TEmSeed(seed=1.0) TRACK L3TTrack ELE_LOOSE ELE(EMSEED=EM_SEED, TRACK=TRACK,
isolation=0.1, EMFR=0.9, likelihood=1.0)
Amber Boehnlein
FNAL Computing Division
Wilson Hall 9W
(630)840-2937