Second Workshop - Trigger Simulation Upgrade
--------------------------------------------

March 13th, 2002  13:30-15:30 ROB 233

Minutes and Notes
-----------------

-----
Valerie Halyo presented a plan from herself and Gerald Genier for a more
detailed layout of the L1DctSimModule components.

  Each trigger board (TSF/BLT/PTD/ZPD/GLT) will take as input an object 
which contains a time-ordered vector (clk4 or clk8) of the needed physics 
inputs, and will produce a similar object containing the needed output 
for each time tick.  The difference from the current trgDC code is that 
each module will process data only once per event, looping over time 
internally.  It was noted that additional intermediate buffers (which
map perfectly to the SimDigi objects discussed above) could be created, 
for instance separating the TSF->BLT output from the TSF->PTD or TSF->ZPD 
output might be desireable.

  Valerie also proposed that the core functions needed for the production
simulation code could be encapsulated in one object (ex: L1DctTsfModule),
while a second module which contains added external functionality for 
trigger studies and teststand code could be written (ex: L1DctTsfExtModule)
inheriting the core algorithms from the central module.  The pros and cons
of this approach were discussed at length, and no real decision was made.

Note:  Depending upon what kind of extra functionality is needed, the 
       SimDigi objects may have all of the needed info, and a separate
       class can be used (without inheritence) to do the work.  Things
       like writing VHDL output should probably be included in the
       SimDigi objects directly, or an extra class could be written
       to do this directly from the SimDigis...

  Valerie further presented some ideas for how to configure the code
to reflect the old/new hardware configuration, and other general concerns
with the configuration options.  It was agreed that a `switch method' was
preferred to other options, as it could be easily overridden by the user.
A long discussion ensued over the desired default behavior in the production
simulation, and it was agreed that by default the date of the background
overlay event should determine whether the old or new hardware configuration
was used.  This ensures the proper luminosity weighting of Monte Carlo
samples.  Since the background overlay events contain front end data
only, and should work perfectly well for the simulation of old/new
hardware, the user/expert should be able to change this if desired.

  There was also some discussion about what type of data to include
in the SimDigi objects, and how the various board-level algorithms
should process this data.