scott snyder 29-Dec-1995 Trigparse 2.09 Trigparse is a tool for generating configuration files from a higher-level syntax comparable to that used in the descriptions of the d0 trigger setup in the d0news TRIGGER folder. 1. How to use trigparse ----------------------- Trigparse is set up by @d0$configs$setup_coor_sim. Among other things, a symbol TRIGPARSE is defined. $ trigparse $TRIGPARSE d0$configs$coor_sim:V3-1.triglist will give you a nontrivial example The output files will be written to the current directory, and the top-level file will have the same name as but with an extension of `.cfg'. To specify a different top-level file, use trigparse Several command line options are available. These must appear after the filename(s): -verbose Print the name of each file as it is written. -quiet No output to the terminal except for errors (default). -version Prints the version of trigparse before starting processing. -prefix Sets the prefix which is tacked on to the front of file names when generating configuration files. The default is `reqs:'. -online This switch changes some of the trigparse defaults to be appropriate for online configurations, as opposed to for the trigger simulator. The changes are equivalent to the following trigparse statements: trigger_defaults readout d0_detector l2_type regular; filter_defaults stream all; filter_defaults filters l2setup (timing_type = clock, banks_to_drop = caep_muoh_muhp_samh_saph_muhm_emsv); In addition, the file prefix is changed to `cfg:'. -cms This switch instructs trigparse to write a list of all files it outputs into (excluding itself). The name of each file will be prepended with the string `$ cmsupdate ', so this file can be executed as a command file from DCL to check the output files CMS (assuming an appropriate definition of `cmsupdate' has provided). -resource This switch tells trigparse to read a COOR trigger resource file (i.e., trig_config.ctl). Trigparse will make a list of the names of the specific triggers and and/or terms present in the file, and will issue a warning if there is an attempt to reference an item not defined in the resource file. Trigparse returns a completion status of 1 if it was successful, or 2 if there was an error in the input file. 1.1 The rest of the document: ---------------------------- The contents are as follows: 2. Input to Trigparse 2.1 Term Lists 2.2 Level 1 2.3 Examples of trigger definition statements: 2.4 Reference sets 2.5 Predeclared reference sets: 2.6 Level 2 2.7 Duplicate filter and trigger definitions 2.8 Predefined macros 3.0 Variants 4.0 Changing defaults 4.1 The eval hook (adding or changing level 2) 4.2 L2 tool definition format 4.3 CL1.5 definition format 5.0 Other statements 5.1 Configtype 5.2 Version 6.0 Legal niceties 7.0 Informal syntax summary 8.0 Example of a complete configuration file 9.0 Files associated with trigparse 2. Input to Trigparse ---------------------- A trigger definition file consists of a series of statements. Each statement is a list of keywords, each followed by zero or more arguments, and is terminated by a semicolon. With few exceptions, keywords can be listed in any order and may be repeated. If the keyword specifies an object of which there can be more than one (such as a stream), then all the keywords of that type in the statement contribute to a list; otherwise, the value of the last keyword in the statement is used. Case is insignificant, and line breaks are treated as whitespace. Comments are introduced by a bang (`!') and extend to the end of the line. A crude macro facility is provided. Define a macro using the syntax define { }; After reading this definition, trigparse will substitute whereever it sees . Macros are not expanded in comments or in quoted strings. Each trigger definition consists of a level 1 trigger definition statement followed by zero or more level 2 filter definition statements. 2.1 Term Lists ---------- Term lists are used to specify the level 1 and-or terms comprising a level 1 trigger and the level 2 tools comprising a level 2 filter. The syntax for a single term is a name followed by an argument list in parentheses: term(arg1, arg2) Arguments in the argument list can be separated either by commas or slashes. An argument can be either named or positional. A named argument has the syntax ` = ', and explicitly provides a value for the named parameter. Positional arguments do not contain an `='. Each term/tool has a list of positional arguments it expects; as positional arguments are scanned, they are associated one-by-one with the parameters in the list. When the end of the list is reached, all parameters on the term/tool's positional argument list must have been defined, either by a positional or named argument. Terms can be combined into a term list by separating them with ampersands. The meaning is to require the logical conjunction of all the terms in the list. Level 1 terms can be preceded with `not' to specify a veto. String arguments are converted into upper case on output, unless they are quoted with single quotes. Standard C (and emacs) backslash escapes may be used within quoted strings. Examples of term lists: em(2,2/none) & not mu(1,1) l2em(1, 10/ele, track_match=require) & l2jt(2,5) & l2ms(20) 2.2 Level 1 ------- A level 1 trigger definition statement starts with the keyword TRIG_BIT followed by the logical name you wish to assign to the trigger. The remaining keywords which can appear in a trigger definition statement are as follows: spec_trig Gives the name of the Level 1 specific trigger bit to request. If omitted, it defaults to `spec_trig'. prescale Specifies the initial prescale for this trigger. If omitted, it defaults to 1. prescaling If this keyword is present, prescale_cntrl will always be set ON. Otherwise, it is on only if the prescale is not 1. readout_msec Specifies the amount of time this trigger takes to read out. If omitted, it defaults to 30. readout Specifies a configuration file to control what portion of the detector is read out, or to perform other setups. The file specified, with a prefix of `reqs:' and an extension of `.req' is included from the .trig file. This keyword can be repeated to include a list of such files. If omitted, it defaults to `all_crates'. l2_type one_l2_node These keywords define the types of level 2 nodes which can handle this trigger. `l2_type ' will generate a type definition of `l2_type $all' and `one_l2_node ' will generate a type definition of `l2_type $one'. These keywords may be repeated to specify a list of such definitions. If neither keyword is present, the type definition defaults to `l2type vms_filter $all'. stream Specifies the stream to which events passing this trigger should be written. This keyword may be repeated to specify a list of streams. If the results of this trigger should not be recorded on any stream, specify the special value `$none'. If omitted, the stream defaults to `$none'. terms A list of level 1 and-or terms which comprise this trigger. The syntax is as described above for term lists. The presently implemented level 1 terms are: specterm(termname) Reference a specific named and-or term. If the `-resource' switch was used, then the `specterm()' can be omitted (i.e., you can use just `termname'). sc(e) Scalar Et > e GeV sc_em(e) Electromagnetic scalar Et > e GeV sc_had(e) Hadronic scalar Et > e GeV ms(e) Missing Et > e GeV jt(n, e) At least n jets with energy e. `E' is actually a key for a reference set of type `l1jt'; see ``Reference sets'' below. lt(n, e) At least n large tiles with energy e. `E' is actually a key for a reference set of type `l1lt'; see ``Reference sets'' below. em(n, e/had) At least n EM towers with energy e and hadronic veto had. `E' and `had' are actually keys for reference sets of types `l1em' and `l1em-hadveto' respectively; see ``Reference sets'' below. mu(n, g) At least n muons within an angle specified by g. If g is an integer or a floating-point number, it is interpreted as follows: g <= 1: cf 1 < g < 2: cf+wn+ws g <= 2: cf+en+es g <= 3: cf+en+es+sn+ss Otherwise, g is interpreted as a string, and is upcased and placed inside of parentheses. mu15(n, g, p) At least n mus within an angle specified by g above momentum p. g has the same meaning as for the `mu' term. p should be either `low' or `high', to refer to the hardwired mu1.5 threshholds. 2.3 Examples of trigger definition statements: trig_bit min_bias terms specterm(zero_bias) prescale 50000; trig_bit em_medium terms em(1,5/none) prescale 200; trig_bit top_to_mu_e spec_trig spec_trig_19 terms mu(1,3) & em(1,5/none) readout d0_data_all l2_type l2_filter; 2.4 Reference sets -------------- A reference set is a file on disk used as input to the level 1 trigger. Reference sets are classified into `types', such as jet reference sets or EM reference sets. There are currently four types: l1jt --- level 1 jet trigger l1lt --- level 1 large tile trigger l1em --- level 1 EM trigger l1em-hadveto --- level 1 EM trigger, hadronic veto Within a single type, reference sets are distinguished by a `key', which is a string unique across all the reference sets of its type. This key is often a number indicating an energy cut, but they are not restricted to this usage. A reference set is declared with a `refset' statement, which consists of the keyword REFSET followed by the filename of the reference set being declared. (This should be the filename only; the rest of the path is added automatically.) The following two keywords must also appear: type Specifies the type of the reference set being declared. key Specifies the key of the reference set being declared. In addition, the text of the reference set file may be specified within a pair of open/close braces. Any text within the braces is written to the file specified in the refset statement with no interpretation. Examples of reference set declaration statements: refset em_low.rs type l1em key 2; refset jet_high.rs key 9 type l1jt { ! 60 GeV Et Jet Reference Set TT_ETA(-20:20) TT_PHI(1:32) THRESH_ET # (9) GeV }; 2.5 Predeclared reference sets: ------------------------------ The following declarations are present when trigparse starts up. They may be redeclared to override these declarations. refset jet_low.rs key 3 type l1jt; refset jet_medium.rs key 5 type l1jt; refset jet_high.rs key 9 type l1jt; refset jet_max.rs key 20 type l1jt; refset em_low.rs key 2 type l1em; refset em_medium.rs key 5 type l1em; refset em_high.rs key 10 type l1em; refset no_had_veto.rs key none type l1em-hadveto; 2.6 Level 2 ------- A level 2 filter definition statement starts with the keyword FILT_BIT followed by the name of the filter bit being defined. The remaining keywords which can appear in a filter definition statement are as follows: pass_1_of Specifies the ratio of events which are forced through the filter without actually filtering. If omitted, it defaults to 0, which means that no events should be force-passed. speed Supposedly indicates how much time the filter takes. I don't think this is really implemented by level 2... If omitted, it defaults to 1. must_try try_as_needed Selects must_try/try_as_needed mode. If neither is present, the default is must_try. stream Specifies the stream to which events passing this filter should be written. This keyword may be repeated to specify a list of streams. If the results of this filter should not be recorded on any stream, specify the special value `$none'. If omitted, the stream defaults to `all'. filters A list of level 2 filters which comprise this filter. The syntax is as described above for term/tool lists. The presently available level 2 tools are: cdc_l2trk () CDC tracking tool for cosmic tests. Additional parameters and defaults: min_segement: 3 sw_per_seg: 5 num_of_trk 1 cosmic_l2_fdc () FDC tracking tool for cosmic tests. cosmic_vtx () VTX tracking tool for cosmic tests. Additional parameters and defaults: pk_thresh: 16 nw_thresh: 4 sec_thresh 1 lay_thresh 3 wend 1 l2em (num_em, etmin_cc, type) L2_EM tool. TYPE is actually a dummy, used to set values for the three parameters SHAPE_CUTS, TRACK_MATCH, and DO_ISOLATION as follows: TYPE SHAPE_CUTS TRACK_MATCH DO_ISOLATION ele ELECTRON REQUIRE false gam PHOTON IGNORE false gis PHOTON IGNORE true esc NONE IGNORE false e_esc E_NONE IGNORE false g_esc G_NONE IGNORE false p_esc P_NONE IGNORE false long LONG IGNORE false e_long E_LONG IGNORE false g_long G_LONG IGNORE false p_long P_LONG IGNORE false trans TRANS IGNORE false e_trans E_TRANS IGNORE false g_trans G_TRANS IGNORE false p_trans P_TRANS IGNORE false Any of these parameters can be overridden individually by explicity including it in the parameter list (e.g., `l2em (1,1,ele, track_match=false)'). Additional parameters and defaults are: etmin_ec: if unspecified, it defaults to the value given for etmin_cc del_eta_track: 0.03 del_phi_track: 0.03 cone_delta_r: 0.4 cone_fract_max: 0.15 tight: false This is not a real parameter, but if it set to `true', the string `_TIGHT' will be appended to the shape_cuts string (provided shape_cuts was specified implicitly via TYPE). l2jt (num_jets, etmin) L2jets tool. Additional parameters and defaults are: core_delta_r: 0.7 veto: false size_min: 0. size_max: 100. empct_min: -999. empct_max: 999. l2ms (etmiss_min [, etmiss_sig_min]) L2etmiss tool. l2mu (num_muons, abs_eta_max, ptmin) Muon_l2 tool. Additional parameters and defaults are: muon_quality: GOOD track_in_road: ALL_(Y3) cosmic_reject: false refit_t0: false scint_on_track: false cal_on_track: false cd_on_track l2prescale (l2_prescale_by [, med_prescale_by, high_prescale_by, max_prescale_by]) Prescaling in level 2. Note that it is recommended that any prescaling be done by level 1 if possible. If not specified, the med_prescale_by, high_prescale_by, and max_prescale_by parameters default to the value given for l2_prescale_by. l2sc (etsum_min [, etot_max]) L2etsum tool. The default for the optional parameter is: etot_max: 100000. l2setup () Dummy tool to initialize the filter system. Additional parameters and defaults are: time_script: true time_tool: true histo_script: false histo_tool: false timing_type: CPU tmin_script: 10. tmax_script: 1010. tmin_tool: 10. tmax_tool: 1010. raw_to_drop: NONE banks_to_drop: NONE banks_to_drop_2: NONE l2_hitfind: false An instance of this tool will be automatically added to the first filter script if one is not already present. The values for `banks_to_drop' and `banks_to_drop_2' should be a list of bank names separated by underscores. If the list specified for `banks_to_drop' is too long to be handled by COOR and no value was specified for `banks_to_drop_2', then the list will automatically be split and continued as `banks_to_drop_2'. l2tau (jet_rms_max, jet_met_dphi_min, jet_jet_dphi_max, num_jets_min, jet_et_min, met_min) W -> tau tool. l2tool1 () Dummy tool for testing. Additional parameters and defaults are: test1: 0 test2: 1.0 l2_acol_jets ([del_phi_jets], [del_phi_met]) Jet acolinearity tool. Parameters and defaults are: jet_cone: 0.7 del_phi_jets 0 del_phi_met: 0 del_phi_met_iso: 0.25 l2_andor_check ([term1, term2, term3, term4, term5]) Tool to check for specific and/or terms. The parameters are term names. Any omitted parameters default to 'IGNORE'. Note that to specify a veto, the parameter value should be given as a string and in upper case; e.g., l2_andor_check (term1, 'TERM2/VETO'); l2_confirm_l15 ([num_l15_muons, l15_regions, p]) Tool to confirm that L15 fired. NUM_L15_MUONS is an integer, and L15_REGIONS is a muon L1 region specifier with the same syntax as for L1 muon triggers. `p' is an optional parameter to specify the hardwired threshhold. It should be either `low' or `high', and defaults to `low'. There is one additional parameter, L15_CONFIRM_TYPE, which defaults to `MUO'. If it is set to `CAL', then the tool does calorimeter l1.5 confirmation instead of muon confirmation, and all other parameters are ignored. l2_etacut (object, num_found [,etmin, abs_eta_max, abs_eta_min, gapcut]) Eta cut tool. OBJECT must be one of the strings JET, MUON, ELECTRON, or PHOTON. Defaults for the optional parameters are: etmin: 0. abs_eta_max: 10. abs_eta_min: 0. gapcut: 0. l2_keep_cd_raw Used to control which raw CD banks to keep after doing hitfinding. It takes one optional parameter: raw_to_keep: CDD1_CDD2_CDD3 l2_masscut (object mass_min) Invariant mass cut tool. OBJECT must be one of the strings JET, MUON, ELECTRON, or PHOTON. Additional parameters and defaults are: nobjects: 2 leading: false eta1_min: -999 eta1_max: 999 eta2_min: -999 eta2_max: 999 abs_etaboost_min: 0 abs_etaboost_max: 999 mass_max: -5000 l2_min_bias (abs_z_max) Min-bias vertex filter. There is one additional parameter: vertex_quality: 'FAST_Z_GOOD' It appears that the present implementation of the filter ignores its parameters. l2_sumjet ([sum_et, eta_limit, vector_sum]) Tool to cut on scalar or vector sum of jet energies. The defaults for the parameters are: sum_et: 100 eta_limit: 2.0 vector_sum: false pass_fail (should_pass) Tool which either always passes or always fails, as given by the logical parameter SHOULD_PASS. Examples of filter definition statements: filt_bit min_bias filters l2tool1() & l2setup(); filt_bit electron_high filters l2em(1,10/ele); filt_bit top_to_mu_e filters l2em(1,5/ele) & l2mu(1,2,5); 2.7 Duplicate filter definitions -------------------------------- Since the output file containing the filter script takes its name from the name you assign to the filter bit, you can get in trouble if you mention the same filter name twice with different parameters. However, it may also be desireable to use filter definitions more than once. Trigparse deals with this in the following way: if a duplicate filter name is seen, a warning is issued unless the new definition looks identical to the previous definition. In this case no .filt file is generated; instead, a reference is made to the previously-generated .filt file. A filter definition looks identical to a previous definition if (1) every keyword specified in the new definition was also specified in the previous definition with the same values, and (2) the filter defaults have not been changed since the previous definition. Note that this implies that once a filter has been defined, one can reference it by specifying only the name. As an exception to the above, the `stream' keyword is ignored when deciding whether or not two definitions are identical. This is because the stream information gets written to the .trig file rather than the .filt file. A duplicate trigger name is an error. 2.8 Predefined macros --------------------- The following predefined macros are provided: define_monitor_stream -> trig_bit lumin_mon spec_trig spec_trig 30 terms dead_time stream monitor 3.0 Variants ------------ It is possible to use trigparse to generate a set of configurations with different cut values, prescales, etc. Each separate configuration is called a _variant_. These sets will share files for the parts of the configuration which are identical for all of them; files which differ for each variant will be distinguished by adding a tag to the end of the name. This tag is the name of the variant. Trigger and filter names are also made unique in this manner. There are two steps to using variants. First, the names of all the variants must be declared at the beginning of the trigparse source. Then each value which should be different in different variants is replaced by a list of values, one for each variant. Variants are declared with the `variants' statement. This must be the first statement in the input file. The body of the statement consists of a list of variant names, separated by whitespace and terminated by a semicolon. Example: variants l02 l05 l10 l20; This declares that there are to be four varients. The files, triggers, and filters specific to the first variant will be distinguished by appending `-l02' to the ends of the names, and similarly for the other variants. To specify a value which is different for each variant, give a list of values in square brackets ([ ]). For example, the construction trig_bit a prescale [10 20 40 80] will yield a trigger bit which has a prescale of 10 in the first variant, 20 in the second, and so on. More precisely, the values inside the brackets are lexical tokens, and there must be exactly as many tokens as there are variants. However, what if you want a value which consists of several tokens or a null value? This can be done by using macros (since variable processing is done before macro expansion), as in the following example: define express { stream all stream exp_express }; define nul { }; filt_bit a [express nul]; The effect of this is to send the result of the filter `a' to the streams `all' and `exp_express' in the first variant, and to take the default in the second. Trigparse attmept to determine which triggers/filters are different and give them unique names, while allowing the variants to share files which are the same for all variants. In the present implementation, however, there are a few situations in which files which could be shared aren't: - If a level 1 trigger is varied, each variant will have its own .lev1 file, even if the changes are only in the .trig file. Note, though, that if the changes are only to a filter, then only one .lev1 file will be generated (but there will be several .trig files, as each has to reference a different .filt file). - Stream assignments are considered part of the information defining a filter. Thus, if a filter is going to different streams in each variant, then each variant will have its own .filt file for that filter (even though the stream information resides entirely in the .trig file). In short, trigparse should always generate a correct set of configurations, but it may emit more files then are strictly necessary. Also, the text inside a variable expression should not contain either the `filt_bit' or `trig_bit' keywords. 4.0 Changing defaults ----------------- The default values for keywords in trigger and filter definition statements can be changed. This is done with a statement starting with either of the keywords TRIGGER_DEFAULTS or FILTER_DEFAULTS; the remainder of the statement should consist of a list of keywords and values as they would appear in a TRIG_BIT or FILT_BIT statement. These values then become the defaults for subsequent trigger and filter definitions. Note that some keywords cannot be assigned default values. Defaults for L2 tools can be changed by including a filter list in the filter_defaults statement. Examples of defaults declaration statements: trigger_defaults readout_msec 100; filter_defaults stream stream1 stream stream2; filter_defaults filters l2mu(track_in_road=false); 4.1 The eval hook (adding to or changing level 2) ------------------------------------------------ The statement eval ; will evaluate the Lisp S-expression given by . The return value is ignored. The construction `eval ' may also be used anywhere within a statement where a keyword may appear (except at the beginning of the statement). This feature can be used to extend trigparse without rebuilding it. For example, the contruction eval (setq l2tool-newtool '("newtool" (param1 param2) (param1 "0.0" l2tool-floatparam) (param2 "0.0" l2tool-floatparam))) ; will define a new level 2 tool named `newtool' with two real parameters named `param1' and `param2'. You can find the current default setups in trigparse.el . Copying them to the start of a .triglist file and using EVAL on the modified versions will give you the revised set of defaults. 4.2 L2 tool definition format ----------------------------- Here's a summary of the Lisp structures which define a L2 tool. To define a L2 tool, bind a list to the symbol `l2tool-', where is the name of the tool as it appears in the trigparse input file. The list should have the following form: ( [...] ) is a string giving the name of the tool as it should appear in the output file. is a list giving the parameter names to associate with positional parameters in the tool argument list. Thus, if was `(arg1 arg2)', the user could refer to the tool with `thetool(1,2)'. `arg1' would then have a value of `1' and `arg2' would have a value of `2'. Each argument listed in must also be listed in an . It is an error if the user fails to specify values for all the parameters in . However, if the special symbol `&optional' appears in the list, then only parameters appearing before it are required. There should be one for each parameter to the tool which should be listed in the filter script. Each is a three-element list with the following format: ( ) is the name of the parameter, as a lisp symbol. (More precisely, it is a lisp symbol, the print name of which is desired parameter name.) is the default value for the parameter, as a string. Note that if the parameter is listed in , then the default will not be used. is a lisp function which will actually write the parameter to the output file. It is called with arguments (NAME VAL TOOLARGS), where NAME is the parameter symbol, VAL is the value which the user specified, and TOOLARGS is the alist of parameter-value pairs produced by the term parser. Output procedures exist for the common datatypes: l2tool-intparam l2tool-floatparam l2tool-stringparam l2tool-boolparam Through approriate use of output functions, parameters can be made to depend on other parameters. See the l2em tool for an example. 4.3 CL1.5 definition format --------------------------- A calorimter L1.5 term is defined with the following syntax: (def-cl15term em (n e) (refset "em" (e "5" (l1term-refset-param l1em-refset-alist))) (local "l_em_loose" (lparm1 "10" l2tool-natnumparam) (lparm2 "5.5" l2tool-floatparam)) (global "g_em_loose" (n "1" l2tool-natnumparam) (gparm1 "0" l2tool-natnumparam) (gparm2 "4.4" l2tool-floatparam))) The first argument is the name of the term. It will automatically have a `cl15-' prepended. The second argument is the list of required arguments to the term. Following these two arguments must be three more lists, starting with `refset', `local', and `global'. They may be listed in any order; however, exactly one of each must be present. The `refset' argument defines the reference set for this tool. The first argument is the refset type, as COOR should see it. The second argument is a level-1 term argument descriptor for the reference set argument. The `local' argument defines the local portion of the tool. It consists of the name of the local tool followed by level-2 argument descriptors for the arguments taken by the local tool. The `global' argument is just like the `local' argument, except that it is for the global tool. A cl15 trigger is used like an ordinary level-1 term. Its name is given by prepending `cl15-' to the name given in the definition, and its required and optional arguments are as specified in the definition. In addition, there are several additional arguments which may be specified for cl15 terms: name (string): The name used for the .l15 file. This argument is required. pass_1_of (natnum): Sets the pass ratio. Default is 0. specterm (string): Sets the name of the L1 trigger term to program. Default is the generic `cal_l15'. Thus, the above definition could be used something like: trig_bit foo terms specterm(good_beam) & cl15-em (5, 10, gparm2 = 123, pass_1_of = 1, name = footerm, specterm = cal_l15_0); 5.0 Other statements -------------------- 5.1 Configtype -------------- A configtype statement has the form configtype ; where is a list of keywods separated by spaces. If present, this statement will cause the third comment line in the top-level configuration file(s) to contain the keyword list in the form This is a ** ** configuration. 5.2 Version ----------- A version statement has the form version ; where is a string identifying the version of this trigger configuration. If present, this statement will cause the first comment line in the top-level configuration file(s) to contain the string `*version: *'. 6.0 Legal niceties -------------- Trigparse is based on GNU Emacs, which is Copyright (C) 1990 Free Software Foundation, Inc. For information on further redistribution or on obtaining sources, please contact fnald0::snyder. 7.0 Informal syntax summary ----------------------- ::= [] ... :== variants ... ; ::= [...] ::= ::= trig_bit [...] ; ::= spec_trig ::= prescale ::= readout_msec ::= readout ::= l2_type ::= one_l2_type ::= prescaling ::= stream ::= terms ::= eval ::= filt_bit [...] ; ::= ::= pass_1_of ::= speed ::= must_try ::= try_as_needed ::= stream ::= filters ::= eval ::= ::= & ::= not ::= ( ) ::= ::= , ::= / ::= ::= = ::= ::= ::= ::= ::= ::= ::= refset [...] ; ::= type ::= key ::= { } ::= eval ::= trigger_defaults [...] ; ::= filter_defaults [...] ; ::= eval ; ::= configtype ; ::= define { } ; 8.0 Example of a complete configuration file ---------------------------------------- ! trigger list v4.1 ! these three lines clear out the default refset definitions eval (setq l1em-refset-alist nil); eval (setq l1em-hadveto-refset-alist nil); eval (setq l1jt-refset-alist nil); ! reference sets ------------------- ! -- l1jt -- refset jet_low.rs key 3 type l1jt { ! 20 GeV Et Jet Reference Set TT_ETA(-20:20) TT_PHI(1:32) THRESH_ET # (3) GeV }; refset jet_medium.rs key 7 type l1jt { ! 40 GeV Et Jet Reference Set TT_ETA(-20:20) TT_PHI(1:32) THRESH_ET # (7) GeV }; refset jet_high.rs key 14 type l1jt { ! 60 GeV Et Jet Reference Set TT_ETA(-20:20) TT_PHI(1:32) THRESH_ET # (14) GeV }; refset jet_max.rs key 25 type l1jt { ! 100 GeV Et Jet Reference Set TT_ETA(-20:20) TT_PHI(1:32) THRESH_ET # (25) GeV }; ! -- l1em -- refset em_low.rs key 2 type l1em { ! 2 GeV Et EM Reference Set TT_ETA(-19:19) TT_PHI(1:32) THRESH_ET # (2) GeV }; refset em_medium.rs key 6 type l1em { ! 6 GeV Et EM Reference Set TT_ETA(-19:19) TT_PHI(1:32) THRESH_ET # (6) GeV }; refset em_high.rs key 12 type l1em { ! 12 GeV Et EM Reference Set TT_ETA(-19:19) TT_PHI(1:32) THRESH_ET # (12) GeV }; ! -- l1em-hadveto -- refset no_had_veto.rs key none type l1em-hadveto { ! No Hadronic Veto Reference Set TT_ETA(-20:20) TT_PHI(1:32) Thresh_ET # (1000) GeV }; ! triggers ------------------------------ ! minimum bias trigger trig_bit min_bias spec_trig spec_trig_0 terms specterm(zero_bias) prescale 3000000; filt_bit min_bias filters l2tool1() & l2setup(); !! filt_bit good_lvl0 filters l2l0(); ! scalar Et `zoo' trigger trig_bit scalar_et spec_trig spec_trig_1 terms sc(150); filt_bit scalar_et filters l2sc(300); ! missing Et SUSY trigger trig_bit missing_et spec_trig spec_trig_2 terms ms(23); filt_bit missing_et filters l2ms(30); filt_bit miss_et_x filters l2ms(50) stream express stream all; ! QCD jet trigger for jets over 20 GeV trig_bit jet_low spec_trig spec_trig_5 terms jt(1,3) prescale 20000; filt_bit jet_low filters l2jt(1,15); ! QCD jet trigger for jets over 40 GeV trig_bit jet_medium spec_trig spec_trig_6 terms jt(1,7) prescale 1000; filt_bit jet_medium filters l2jt(1,30); ! QCD jet trigger for jets over 60 GeV trig_bit jet_high spec_trig spec_trig_7 terms jt(1,14) prescale 50; filt_bit jet_high filters l2jt(1,50); ! QCD jet trigger for jets over 100 GeV trig_bit jet_max spec_trig spec_trig_8 terms jt(1,25); filt_bit jet_max filters l2jt(1,110); ! Calibration trigger trig_bit jet_calb spec_trig spec_trig_9 terms jt(1,7) & sc(100) prescale 20; filt_bit jet_calb filters l2jt(1,7) & l2sc(100); ! top to jets trigger trig_bit four_jets spec_trig spec_trig_11 terms jt(4,7); filt_bit top_jets filters l2jt(4,20); ! prescaled gamma trigger trig_bit em_low spec_trig spec_trig_14 terms em(1,2/none) prescale 40000; filt_bit em_low_esc filters l2em(1,6,e_esc); filt_bit gam_low filters l2em(1,3,gam); ! prescaled electron/gamma trigger trig_bit em_medium spec_trig spec_trig_15 terms em(1,6/none) prescale 400; filt_bit em_med_esc filters l2em(1,20,e_esc); filt_bit gam_medium filters l2em(1,10,gam); filt_bit gam_med_iso filters l2em(1, 6,gis); filt_bit ele_medium filters l2em(1, 8,ele); ! W, t to electron trigger trig_bit em_high spec_trig spec_trig_16 terms em(1,12/none); filt_bit em_high_esc filters l2em(1,50,e_esc); filt_bit ele_high_x filters l2em(1,35,ele) stream express stream all; filt_bit ele_high filters l2em(1,20,ele); filt_bit gam_high filters l2em(1,40,gam); filt_bit gam_high_iso filters l2em(1,25,gis); ! psi, gamma to two electrons trigger trig_bit two_em_low spec_trig spec_trig_17 terms em(2,2/none) prescale 2000; filt_bit two_em_esc filters l2em(2,6,e_esc); filt_bit two_ele_low filters l2em(2,2,ele); ! Z, upsilon, gamma to two electrons trigger trig_bit two_em_med spec_trig spec_trig_18 terms em(2,6/none); filt_bit two_ele_med filters l2em(2, 8,ele); filt_bit two_ele_x filters l2em(2,10,ele) stream express stream all; filt_bit two_gam_med filters l2em(2, 8,gam); ! B to mu and psi ee trigger trig_bit mu_two_em spec_trig spec_trig_21 terms mu(1,3) & em(2,2/none); filt_bit mu_psi_e filters l2em(2,2,ele) & l2mu(1,2,0); ! B to mu prescaled trigger trig_bit mu_low spec_trig spec_trig_22 terms mu(1,3) prescale 200; filt_bit mu_low filters l2mu(1,2,3); ! b, Z, t -> mu mu trig_bit two_mu_low spec_trig spec_trig_23 terms mu(2,3); filt_bit two_mu_low_x filters l2mu(2,2,3) stream express stream all; filt_bit mu_psi_mu filters l2mu(3,2,0); ! t to e, mu trigger trig_bit mu_and_em spec_trig spec_trig_24 terms mu(1,3) & em(1,6/none); filt_bit top_mu_e_x filters l2em(1,6,ele) & l2mu(1,2,5) stream express stream all; ! t -> mu + jets trig_bit mu_and_jets spec_trig spec_trig_25 terms mu(1,3) & jt(2,7); filt_bit top_to_mu_j filters l2jt(2,25) & l2mu(1,2,0); ! W, Z, t -> mu trig_bit mu_high_cent spec_trig spec_trig_26 terms mu(1,3); filt_bit mu_high filters l2mu(1,2,7); filt_bit mu_high_x filters l2mu(1,2,10) stream express stream all; ! Z, t -> mu mu trig_bit two_mu_cent spec_trig spec_trig_27 terms mu(2,3); ! kluged geometry... filt_bit two_mu_cen filters l2mu(2,2,0); filt_bit two_mu_cen_x filters l2mu(2,2,5) stream express stream all; ! Calibration trig_bit mu_cent spec_trig spec_trig_28 terms mu(1,3) prescale 4000; filt_bit mu_central filters l2mu(1,2,0); 9.0 Files associated with trigparse ---------------------------------- trigparse.exe: bare emacs, compiled for trigparse with some features removed trigparse.dump: dumped lisp code, including trigparse trigparse.alpha-exe: trigparse.alpha-dump:the same, for the alpha. setup_trigparse.com: defines a command `trigparse'. assumes the first two files are located in d0$configs. trigparse.el: emacs-lisp source for trigparse trigparse.elc: byte-compiled version of same build-trigparse.com: command procedure used to create trigparse.dump load-trigparse.el: emacs-lisp driver used to create trigparse.dump trigparse.doc: a feeble attempt at documentation (this file) v3-1.triglist: the trigger list, v3.1 v4-1.triglist: the trigger list, v4.1 only the first three files are required for running. The source came from usr$root2:[snyder.trigparse] originally.