Hi Folks,

Here are 
my suggestions for "brainstorming"-type items that we might want 
to discuss amongst ourselves
and with other sections of the D0 trigger community at the trigger
workshop next week.  Your comments on these and suggestions for
additional topics would be very much appreciated.

Regards, Terry.




- I have several open questions in my mind concerning making the best
  possible use of the redundancy of the trigger to get the best
  possible efficiency and lowest systematic errors in the
  determination of the efficiency.  
  For example, let's say I'm someone interested in high pt isolated
  electrons for doing W/Z physics.  There are a large number of pieces
  of information I could use to trigger these events:
   - tracks:  
     + high pt
     + isolation
   - calorimeter
     + high pt
     + isolation
     + transverse and longitudinal shower shape in e.m.
     + veto on HadCal activity (em fraction)
     + preshower match

   Presumably we'd like to run independent track- and
   calorimeter-based filtering, plus a filter based on matched
   calorimeter-cluster-track pairs.

   Plus one can require even looser cuts on Z-ee events.  I.e. one can
   accept events with two very loose electrons, neither of which would
   trigger on its own. 

   We already run two different calorimeter electron filters one which 
   requires high pt and no shower shape and a second that accepts at a
   lower pt, but requires shower shape.  In principle one could
   imagine the number of filters rising with N factorial, where N is
   the number of independent pieces of information.  This is clearly
   not practical. 

   -  If we want a separate L3 trigger_name for each
     different allowed combination we have to restrict the number of
     combinations we consider.  (But even then the limitation of 256 L3
     triggers is a limitation.  How hard would it be to persuade people
     to increase this limit?)

   - Alternatively, we might imagine running one filter that would
     calculate some sort of "electron-score" (not a neural net) based
     on all the available information.  That would have the advantage
     of requiring only one L3 trigger bit, but would mean that it
     would not be possible just from the trigger bits to work out
     exactly why an event triggered or did not trigger.  We would have
     to add enough information to the L3 physics results to make
     trigger studies and efficiency calculations possible.

   (Obviously, I'm assuming that the most demanding physics analyses 
    in terms of understanding
    trigger efficiencies will require a high level of expertise.
    However, for people doing analyses that don't need the state of
    the art in efficiency or systematic errors,
    we will need to provide tools to make the job of selecting the
    right triggers and measuring efficiencies as easy as possible.)





- How much L3 "physics results" type information should we store on
  the thumbnail?  I'm assuming quite a lot!  I think we need to have
  all the information necessary to do trigger studies and efficiency
  calculations based on the thumbnail.  I'm assuming the trigger bits
  themselves will be insufficient for this purpose.
  (My question out of ignorance:  is anything implemented at the
  moment for L3 physics results on the thumbnail?)





- Can we do more sophisticated online monitoring in the L3 nodes?
      (L3 sees data at 1 kHz and does a pretty complete reconstruction
      of these data.)
      * For example, collect histograms, measure efficiencies
      * Make use of the 90% of the events that we reject?  For example:
        + Measure trigger turn-on curves (for L1 and L2 as well as L3)
        + Do background studies
        (Why write out events and have the huge overhead in having to
	 run offline reconstruction and storing them permanently if
         they are needed for relatively simple operations that can 
	 be performed adequately in L3?)
      * Best way to concatenate results from monitor processes running on
        each of the 100 L3 farm nodes not worked out yet.
      * Will require extra resources at L3, but the potential return
        (in terms of spotting trigger problems and in saving offline
        resources) might make this a very cost-effective investment.
	This will also be the case if we find that lack of cpu power
        is limiting the sophistication of the event reconstruction
        and/or filtering that is possible in L3.




- I'm assuming we shall want to start doing event identification asap
  in L3 (eg, W and Z to e, mu, tau).  How will we organise this?  Hang
  W, Z-type filters off of the most relevant L2 bits and set an L3 bit
  for candidate events.  (Obviously, these bits are completely
  redundant for triggering since much looser cuts will have been
  employed in the single lepton filters that will be hanging off of
  the same L1/L2 bits.)  Again, how hard is the limit at 256 L3
  triggers?  Will people complain that we're "wasting" trigger bits?




- It is likely that raw data will be dropped from the reco output in
  the near future.  For trigger (and many other studies) should we be
  proposing to keep raw data for low multiplicity events such as W/Z
  to lepton candidates (as identified by L3).  These events are some
  of the most demanding in terms of measuring detector/trigger/reco
  performance to an accuracy sufficient for the kinds of physics we
  are going to be doing (but are some of the most useful to measure
  detector/trigger/reco performance.



- How easy/difficult is it at the moment to do some of the nuts and
  bolts type things needed for practical trigger studies and verification?
  +  E.g., accessing the actual fired triggers at L1/L2/L3 in real data.
  +  Comparing on and offline results on an event by event basis
  +  Getting trigsim to simulate the full L1/L2/L3 chain.