# Presentation: 340435

## D0 Level 3 filters

**Dan Claes                      Moacyr Souza**
***U. of Nebraska *****             *****Fermilab****** / ******Lafex - Rio de Janeiro***

*Dzero Collaboration Meeting*
*      **November 9th, 2001*

##  status of ScriptRunner

-  status of ScriptRunner
-  status of Filters/Tools
- status of L3 Monitoring

## Build/append/delete pieces of the execution tree, on 

-       demand.
-         status: working properly
- Do the Filter Dispatching
-        -Execution tree implemented as a *linked list pattern*
-       -Intended behavior : never hear about it!
-          1) No logic involved
-          2) There is only *one* way to go : otherwise -> crash
-               This is how robustness was insured
-            status: No complaints!  (never heard about!)
- Gather status & statistics and send Monitoring data
-       to servers  : I will be taking about at the end

-  Digest the coor commands and
-    act according
-      status: working properly after some
-      re-arrangements with L3 Frame

## L3TJet Tool

- 		  seeks 95% rejection of L2-accepts, relying on
-  		  the high precision calorimeter readout available
-                    in L3 and the improved energy and position
-                    resolution this makes possible
- identify (and reject) low-ET events passing L2 trigger
*	**	**	**    **sharpen the turn-on curve*
- may need to introduce additional kinematic cuts
*	**         **dijet mass, jet-lepton angular separations*
**Resolutions** obtained by comparing L3 jets to MC jets
- 			     1/   E  dependence
-                      with best fit constant term of
-        **0.87** (central calorimeter) **1.16** (forward calorimeter)

## L3TJet Tool

_**L3TJet Tool**_
- leading jet pT for JT_HI **failed** and **passed** events

**JT_HI**    CJT(1,10)   **JET_15**(MinEt=15)	    **18.5**
**JT_LO**   CJT(1,5)     **JET_10**(MinEt=10)         **8.77**

**Rejection:**

## Electron Tool currently implemented

***Electron Tool ******currently implemented***
***by filtering on highly electromagnetic jets***

- applies cut on **emfrac**
* **calculated within the* *calorimeter cluster tool*
- EM_LOW:  CEM(1,5) 	PT>7 GeV	 	emfrac>0.9
- EM_HIGH: CEM(1,10) 	PT>11 GeV	emfrac>0.9
*final runs* (132947-133014) *before shutdown* 375K events
*  **included a substantial subset of Mark & Pass’ed events*

- offline studies by ***Ia Iashvili*** (UC-Riverside)

## Rejection = 5.5

- PT recalculated w.r.t. **Z**=0

- PT EM (GeV)

- CEM(1,10)
- PT>11 GeV
- emfrac>0.9

**Rejection** = **5.5**
*sharpens the turn-on*
- (**emfrac** *alone* = 3.6)

***from***** **
**32117 Mark&Passed **
***events***

## PT EM (GeV)

- PT recalculated w.r.t. **Z**=0

- PT EM (GeV)

***from***** **
**32117 Mark&Passed **
***events***

- CEM(1,10)
- PT>11 GeV
- emfrac>0.9

*with the added*
**OFFLINE**
- Good EM Requirements:
- EM fraction > 0.9
- Isolation<0.2
- HM41<200
- |*** *|<0.8

## All events

**ISO**

**HM9**

**HM41**

**Emf**

- Passed events

- No bias observed between filtered and M&P data

##  Rejection = 15

- PT recalculated w.r.t. **Z**=0

- PT EM (GeV)

***from***** **
**525 Mark&Passed **
***events***

- CEM(1,5)
- PT>7 GeV
- emfrac>0.9

-  Rejection = 15
- (**emfrac** *alone* = 2.7)

## L3 EM Certification Ulla Blumenschein (Mainz)

**L3 EM** Certification *Ulla Blumenschein* (Mainz)

- Single electron efficiency in CC fiducial region vs electron *p*T
- L3 EM object    with EMFR>0.9   with track match   with CPS match

##  proposed L3TEle  Electron Tool 

- applying a cut only on **emfrac**
*should duplicate the conditions we ran under at shutdown*
*possibly more rejection available with*
**isolation** cut
- offline (and parallel Mark&Pass filters) will study
- harder shower shape cuts
- preshower calls will be implemented when CPS available

- Plan to come up running a
**fully functional** **tool**
- with the following available functionality:

## L3TCPS  Central PreShower Clustering Tool

***authors: ******Andre Turcot *****(****BNL****)***** ******,Chunhui Han****** *****(****MICH****)***** ***

**Combine **contiguous **strips** *above threshold *
**                 ****into** *single-layer- clusters *(**SLC*****s***)
- 	         for each layer and *hemisphere**.** *
**Apply** a SLC energy threshold **cut****  **
**Search** for *geometrically allowed *combinations
-   	         (of one SLC from each layer)
-                   matched within position errors
-           and with a reasonable energy correlation

- Implements **L3Region** and localized clustering.
*(with either **** or ****  from electron or photon tool)*

- Once CPS readout is commissioned ~2 weeks to implement into L3Ele

## L3TCPS  Tool PERFORMANCE 

***Efficiency defined as***
***clusters matched within 20 mm divided by***
***number of pT>5 GeV e************ ******within CPS fiducial****** ***

***Z*****0*********e******+******e************ ****with 6 Min Bias events*
- Efficiency=293/296 = 99%
***t t  ****events with 7 Min Bias*
- Efficiency  = 76/93 = 82%
- J/*** *(*low *PT) *study *(*for events passing* L1/L2)
- Efficiency  = 76/93 = 86%
- QCD20 *sample passing* L1/L2
- Rejection=17 (track/CPS/cal match)

_**Timing**_
- Regional clustering =2ms
- Unpacking = 5 ms

## l3fCalMEt Missing Et Tool

***author: ******Lee Sawyer****** *****(****Louisiana Tech****)**

- 		     calorimeter cell-based tool
**L3TCalUnpTool**** **provides unpacked cell information
-      	*assumed to include ICD/MG sampling corrections *
**CAL energy stored **(assuming nominal (0,0,0) vertex)
**Missing E****t** calculated through intermediate ******ring sums **
**L3TPrVtxTool**** **returns the most probable primary vertex
**recalculate ring sums** using primary vertex
*currently uses the nominal* (0,0)
**calculates **Missing ET,, , scalar ET, and
-                    Missing ET significance * *
* **no ****muon correction**** included yet*
*      **	**    *_*Ready to run pending certification studies*_

## SMT Unpacking & Clustering Scales with the number of clusters

**SMT** Unpacking & Clustering Scales with the number of clusters

**avg time**
**avg #clusters**

## CFT Unpacking & Clustering Scales with the number of clusters

**CFT** Unpacking & Clustering Scales with the number of clusters

**avg time**
**avg #clusters**

- spread here
- due to
- sorting fibres
- into order

## CFT Tracking Algorithm - L3TCFTTracker

**Initialization **x,y, positions of every fiber calculated
- stored in arrays for fast lookup
- Track-finding in selected **L3Region**s or across **entire** detector
-  Adjacent hits merged into clusters
-    and average x,y, position stored
* **Single track may physically cross no more  *
* **than 3 adjacent fibers in any doublet layer.*
*          **Clusters longer than 3 not used.*
- Tracking proceeds in 2 stages:**axial** followed by **stereo**.
- Separation permits axial tracking ***alone.***
- A fast circle fit (axial layers)
-  identifies candidates as arcs thru the origin.
- A straight line fit in the Sz-plane
-  determines the track helix parameters
***     ******S is the arc length traversed in the xy-plane***

***Principal author: ******Ray Beuselink****** *****(****IMPERIAL****)**
***Daniela Bauer, Robert Illingworth***

- 

- 0

- (xc,yc)

- Sxy

- R

- x

- y

- 0

- d0

## CFT Tracking Algorithm - L3TCFTTracker

**“****Link-and-tree” Algorithm****  - **developed for TASSO, used by ALEPH
**Links **join clustered hits from different layers
**radius** calculated of the circle thru both clusters and the origin
- must exceed radius corresponding to selected PT cut
*         **even a **0.5 GeV/c** cut reduces combinatorics dramatically*
- Links across a missing layer allowed (up to two total missing layers)
**Starting **from a link in the outer layer, candidate **track paths** built by
- adding links from adjacent layers to extend path length
- if curvature consistent with preceding link
- continues recursively.
- The longest extended path found starting from the initial link
-   is kept as a track candidate

## L3TCFTTracker 

- See DØ note 3779 for performance studies.

_**L3TCFTTracker **_
- Example Resolution plots for Z->μμ

## Example Resolution plots for Z->μμ

## Certification

- Some final coding to complete and test
*followed by*
**Certification**
_**L3TVertexFinder**_
- First version of a Primary Vertex tool in test release
- designed to run from CFT tracks, but
- being expanded to include the global tracker
-                      (requires minor mods)
**Certification**

- Ready for online testing	~January, 2002

## L3TSMTTracker - Silicon Microstrip Tracker

***      ******author: ******Daniel Whiteson****** *****(****BERKELEY****)**

**modified “link-and-tree” method** - segments connect neighboring hits
- between points within ******=0.4** (*tunable parameter*)
- segment paths are linked if **z-slope** within **0.2**** **and ****** **within **0.015**** **
-                   (*both tunable parameters*) of previous segment
- without seed info, begin with outermost SMT layer,
- Look for longest paths toward center
- Longest paths fitted to a helix.
- Path with smallest2 selected - its hits marked as in use.
- Paths are to have 4 hits, and not > 2 consecutive missed layers.
- SMT divided into 24  15**O**** **sections.  Track segments may cross
-                             boundaries, but not skip sections.
***Hits on disks ignored.***

## L3TSMTTracker - Efficiency & Purity Studies

-                                                                                correct/incorrect
- Single 5-GeV****     .788              1.0           4.55/  .005           7.44
-  (1000 events)
-    Z  ****                .784              0.929       4.45/  .111           51.3
-   (100 events)
-    Z    ****               .740              0.930       4.51/  .131           50.2
-   (100 events)

**Efficiency:** 2<1.0 and Pt >1.0 GeV cuts applied to all tracks
- “missed” tracks lack full **3D **info - z position placed at strip center

_**L3TSMTTracker - **_**Efficiency & Purity Studies**

## Level 3 Global Track Finding

***author: ******Daniel Whiteson****** *****(****BERKELEY****)**

*                   **preliminary results on a global (*SMT* plus *CFT*) stiff track finder*
* *
**Find axial CFT tracks**
- Track “stubs” - CFT axial hit pairs in outer two layers (X7 and X8)
*having *d/dr < *maximum value determined by *Pt_min
- Linear extrapolation of each stub predicts crossing at next CFT layer
- hits within d/dr added if do not increase 2 by more than 35.0
*Axial tracks required to have* 7 *hits.*
**Match stereo clusters**
- For a given axial track stereo clusters* reconstructing z within CFT*
- hit pairs on outer layers U4 and V4 linearly extrapolated
- sequential least-squares estimate updated w/hits at each radius
- CFT track requires at least 7 axial hits matched with stereo hits
**Extend into SMT**
- A fully fit CFT track can be propogated into SMT
*(see preceding description of SMT Track Extension)*

##  Time depends on PTmin threshold & number of tracks in event

***author: ******Daniel Whiteson****** *****(****BERKELEY****)**

-  Uses ***raw data*** from **CFT**
-  Uses 1-dimensional raw data from **SMT** to avoid cluster ghosts
-  Combines **CFT** and **SMT** information in a globally
-        *rather than simply extending tracks from *CFT
-  **SMT **information helps improve resolution and reject fakes
-  Employs an adaptive histogramming technique for stereo tracking
-  Time depends on PTmin threshold & number of tracks in event

##   Event sample            Pt cut       Efficiency     Purity      Hits per track

-   Event sample            Pt cut       Efficiency     Purity      Hits per track
-                                                                                          correct/incorrect
- Single 5-GeV********       0.0 GeV        1.00             1.00         10.8/  0.03
- Z  **** +0 minbias    2.0 GeV         0.97            1.00          9.95/  0.34
-                                  3.0 GeV         0.96            1.00          10.4/  0.24
-                                  5.0 GeV         0.99            1.00          10.6/  0.17
-                                  10. GeV         1.00            1.00          10.6/  0.17
- Z  **** +2 minbias    2.0 GeV         0.94            0.99          9.92/  0.43
-                                  3.0 GeV         0.97            0.99          10.2/  0.38
-                                  5.0 GeV         0.97            0.99          10.7/  0.39
-                                  10. GeV         0.98            1.00          10.5/  0.31
- Z  ****+0 minbias     2.0 GeV         0.96            1.00          9.93/  0.43
-                                  5.0 GeV         0.97            1.00          10.3/  0.38
-                                  10. GeV         0.97            1.00          10.3/  0.43
- Z  ****+2 minbias     2.0 GeV         0.90            1.00          9.44/  0.72
-                                  5.0 GeV         0.96            1.00          9.75/  0.74
-                                  10. GeV         0.98            1.00          9.69/  0.77

## single track (SMT-only) filter

***author: ******Daniel Whiteson****** *****(****BERKELEY****)**

*single track* (SMT-only) filter
- now under study
*using data*
- to provide additional rejection to
**current** muon, jet filters

## DCA(cm) vs 

- Runs 132167-8:SMT (4 hits) tracks 13000 evts (magnet on)

**#tracks vs ********trk**** at DCA**

**DCA(cm) vs ******
- sine wave also seen offline
- (*vertex not centered*)
- straight bands show noise

**DCA**
**(sine wave subtracted out)**
- tracks within Gaussian
- are highly pure

## Runs 132167-8:SMT (5 hits) tracks 13000 evts (magnet on)

- Runs 132167-8:SMT (**5** hits) tracks 13000 evts (magnet on)

**#tracks vs ********trk**** at DCA**

**DCA(cm) vs ******
- sine wave also seen offline
- (*vertex not centered*)
- straight bands show noise

**DCA**
**(sine wave subtracted out)**
- tracks within Gaussian
- are highly pure

## Filtering data with a simple SMT track Vertexer

- SMT tracks examined
- for 2 or more
- with close z-positions
- at DCA

- Maximal Z-distance
- between tracks in
- a given vertex

- Z MC
- QCD (PT>20)
- Data

## vertex filtered SMT-only efficiencies

- QCD, pt>20, 2.5mb
- Z2.5 mb
- data runs 130167-8

- Z-distance (cm)

- Min pT (GeV)

## L3 Primary Vertex Algorithm

***author: ******Guilherme Lima****** *****(****UERJ/Brazil****)**
**D0Note # 3592** - *J. Zhou, J. Hauptman, and M. Narain*

**Sort** SMT barrel hits in ****
**Define ********-slices** up to 50 hits or ****** = 0.2 **maximum
-                         *discard slices with < 10 hits*
**De-ghost **by defining *roads* using 2o stereo hits and then
-              use 90o hits only when within the road
**Pair hits **with <0.05 rad and r > 1 cm
**Histogram **z-axis projections (*with 1 cm bin width*) of all
-                             hit pairs in each slice
**Threshold selects **vertex **candidate peaks **for each ******-**slice
**Sum slices** counting number of slices contributing to,
-                     and total # of entries in, each candidate peak.
**Discard candidates **with <3 contributing ******-**slices
**Assign probabilities **of (#entries) x (#slices)
**Merge candidates **with separation < 0.5 cm

## L3TPrVtxTool

- t-tbar                          *5000 events**	*X to b-bbar                  *250 events*
- B toKs,  to*1000 events      *B toKs,  to*1000 events*
- Prompt  to e+e-      *1000 events       *W to                       *1000 events*
- W to e                     *1000 events       Z* to                        *1000 events*
*Z* to ee                       *1000 events       Z* to                         *1000 events*
- + jet                        *1000 events*

- 		   Generated hits		 Reconstructed hits
-                   Eff(%)       Resol(m)      Eff(%)     Resol(m)
*t-tbar*		93		620		79		2000
*B    ****K**	*94		510		43		1100
*QCD**	**	*95		500		66		1500

_**L3TPrVtxTool**_

***Dependent on event topology***

_*Has yet to be tested on REAL DATA*_

## L3TMuon author: Paul Balm (NIKHEF)

**L3TMCT**, the calorimeter confirmation tool
**L3TMuoCentralMatch**** (calls**** ****a central track tool)**
- Provides Tracker with region to look for tracks.
- Tracks matched at muon A layer using a ** 2 based on  and 
-  extensively studied w/1000-event 5GeV *p*T single muon sample
- 			   but not yet with real data
*  **Performance studies and certification of these features underway *

_**L3TMuon **_***author: ******Paul Balm****** *****(****NIKHEF****)**
***Martin Wegner, Martin Grunewald *****(****Aachen****)**

**L3TMuoUnpack**** (unpacking tool)****	**
***	***run successfully in **ONLINE** tests but ***not*** yet
-           independent of rapidly changing configuration files
- 	*fix provided by ****Scott Snyder**** to be implemented & checked *

## interim L3TMuon functionality

***interim****** ***_**L3TMuon**_*** ******functionality***
**collect ****Mark & Pass**** data filtering on **
**local muon track**** reconstruction ****only****:**

_**L3TMuoLocal **_*  *(*RunI-style segment finder*)
*Fast reconstruction of the local muon track*
**reconstructs track segments** using the space points (hits) within
- 			            a single module
**links segments **before and after toroid to make full track
- 			*narrowing down **** and P**T*
**adapts OFFLINE** segment and local track algorithms,
- introduces* FAST *segment finder
***	******	******	******         ******pending the ***
***unpacker’s independence of configuration files and ***
***	******	******confirmation of a memory leak fix***

## Continue development and testing to

**stage additional**** Muon Tool ****functionality**
*  *
_***January, 2002?***_
**L3TMuoCentralMatch**** **
*calling* **L3TCFT**** ***fast central track tool when track readout available*
*studies completed with single muon and* BJ/** Ks MC *samples, *
* **but performance tests and certification w/****real data**** still to be completed*
**L3TScint *****author: ******Victor Koreshev****** *****(****IHEP,Russia****)*** *
*constraining track parameters with narrow scintillator time window*
**L3TMTC**** **
**                                    ***verifying MIP trace thru the calorimeter*
**                                   **

## timing   Paul Balm (NIKHEF)

_**L3TMuon**_

- 1000 BJ/** Ks MC sample

- L3MuoUnpacker/calibration		 3 msec/event
- (unpacking of SMT+CFT+Muon      21 msec/event)
- GlobalTracker 				 7 msec/event
- SMTTracker 			         10 msec/event
- CFTTracker                                   >133 msec/event (~15 overflows)
- L3Tmuon tracking 		         66 msec/event
- L3TMuoCentralMatch			 4 msec/event
-                    **~70** ms/evt for local muons *only*
-                    **~95** ms/evt with GlobalTracker match

- 1 GHz
- Clued0

## t

***author: ******Gustaaf Brooijmans****** (*****FNAL*****)***

- 		   pursuing two approaches
**Calorimeter-driven search:**
**  ***Starts with***  **
**  ****L3TCalCluster ***p*T>1GeV** **providing cluster widths and profiles
-   		ET>3GeV  width<0.3  profile>0.25
**  ****L3TCFTTracker **provides *p*T>1GeV tracks, collect those:
-               	*        *** <0.25   *** <*0.4
**Track-based search:**
*Starts from*
-   **L3TCFTTracker **providing *p*T>1GeV**  **CFT
**  **(cluster tracks w/R<0.3), order in **, match with
-   **L3TCalCluster*** *clusters

**t**

- Certifying code, plan to get non-optimized filter into triggerlist,
- gather information online for tuning under online conditions

## ~40msec.  

_**Some Timing Estimates**_

_**Tool**__**	**_**       **_**Timing Estimate**_
- CalUnp 	     **10 msec****/**event	CalCluster        **<1 msec**
- L3jet 		     **<1 msec**
- CPS unpack 	     **<1 msec**		CPS clustering **<1 msec**
- SMTunpack          **10 ms** (~1/2 spent clustering)
- SMT Tracking    **  10 msec**
- Global Tracking     **10 msec**
- CFTunpacking        **2 msec**  (~1/3 spent clustering)
- PrimVtx(SMT)       **2 msec**
- MuoUnp                 3 msec
- MuoSegment        <1 msec
- MuoTrackFitting  66 msec (J/** study)

- on typical (QCD) events
- to cluster calorimeter cells
- and get a primary vertex
**~40msec**.

- muon events
**~70msec**
- with Global trackmatch
**~90msec**.

## Last Run: medium luminosity (6E30)

_**Last Run: medium luminosity (6E30)**_

- -no software vertexing was run
**120-150 msec** avg, but with LONG tails
-                                              (most often due to muon)
- FILTERING time broke down as
- At **145 Hz** into **Level 2**, the nominal budget was
- <Tnom> = Nnodes/ Hz In = 45/145 = .31 sec = **310 msec**.
- Queuing theory warns of deadtime within **0.7 to 0.8** of this number.
- This was the "wall" hit at around a **220-250 msec** processing rate.

- mu                        55 %
- jet                         16
- electron                 13
- Missing ET            11
- Mu confirmation    2
- Sum ET                   2

##  SR duties (other than make the filters dispatching) 

-  Fill the L3Chunk
-    For each filter, record
-        -  status :          passed/failed     (and called)
-        - Unbiased :    L3Unbiased
-                                  L2Unbiased
-                                  “forced_unbiased”
-        - L3prescaled
-        - others
-  Fill the Debug Chunk (on demand)
-       - can vary
-  Fill the Event_Header
-    For each event, record :
-         - L1 active && fired bit mask
-         - L2 active && fired bit mask
-         - L3 active && fired bit mask
-         - Streaming information
-         - run #, event #, Luminosity Block, data_size, ...

##  Send monitoring information at a given heart beat

-  Send monitoring information at a given heart beat
-    For each filter, record
-         - Rates :        # called ,   # passed
-         - Special events :        # L3Unbiased
-                                               # prescaled
-         - Others : Histogram of the overall filtering time/per event
-                            ...
-  and time to time,  send the Tools’ monitoring data (l3fstatmanager):
-             per Tool :        # of candidates
-                                      Timing
-                                      Correlations, others ...
-  Send monitoring information  per Luminosity block
-   For each L2 bit:
-     - # events received
-     - corresponding L2 bit number
-     - L3 bit names   (l3scripts)
-     - L3 prescale factors
-     - # events passed, per filter
-     - # events failed, per filter
-     - # events L3Unbiased

-   All this is already implemented in the SR side
-   All monitoring information are grouped in the
-                   L3MonChunk
-      and SR currently gathers all this information and
-      inserts it into (L3MonChunk)
-  There is only one heart beat:
-     whenever the luminosity block index changes
-  Any other persistent data can be added!

## For the L3 Monitoring Server :

- In the SR / l3fchunk side: L3MonChunk methods
- (together they allow the implementation of the monitoring server)
-  L3MonChunk operator + (L3Monchunk &c1, L3MonChunk &c2)
-      implement  the sum of all elements belonging to the
-      L3MonChunk private members. This is, of course,  crucial to the
-       monitoring server implementation.
-  Void makeMonString( std::string &) :   information for the Daq_Monitor server
-        This method produces a string with all the monitoring information
-        in a format readable by the L3 monitor server.
-   void  makeString( std::stringt &) :    information for the Luminosity server
-        This method produces a string with all the monitoring information
-         per luminosity block and all other information, in a format
-        readable by the luminosity monitor server.

## L3 Monitor Server :

- Main ingredients:
-  Register nodes at start of run time
-  Receive data from the Linux nodes and store them on node’s ( or process ) boxes
-  Set up an alarm to time out nodes that overflow the time slice allotted
-  Sum up information from all active nodes ( processes ) when either all nodes are
-   done or if the alarm fires
-  Produce (string) messages with all the information assembled according, to be sent to
-          - Daq_Monitor_Display server
-          - Luminosity server
-  At the end of run time ( for all or for some nodes )
-    send information to the Run Summary server AND
-    clear all boxes for those nodes ( processes ) that
-    ended.

## L3 Monitoring

- L3 Monitor
- Server

- L3 Nodes

- L3 Nodes

- L3 Nodes

- L3 Nodes

- Run Summary
- Server

- DAQ Monitor
- Display

- Luminosity
- Server

**Information (L3MonChunk**
**as a d0omStream object)**
**is sent, as ITC messages,**
**each time that the luminosity**
** ****index changes**

**Here the information from**
**all actives (not timed out)**
**nodes are summed up**

- L3 Monitoring

**Rates, timing, ... **
**so far**

**Statistics, rates,...,**
**for this luminosity**
** ****index value**

- To be implemented

- Alarm

##               The L3 Monitoring Server

-           Progress/Problems in the last (NT) run
- Progress:
- During the past beam run with NT nodes, we were able to run the Monitor Server and send information to the Daq Monitor. Also we were able to receive the luminosity monitoring information.
- Normally, 4 to 8 NT nodes were active.
- Problems:
- We had several problems, mostly related to ITC messages framework.
- One major problem  was that:
-   A certain number of nodes (2 to 4) always timed out - different ones, though.
-   That made the monitoring display hard to understand for  people not aware of this.
-   That also made the luminosity information more or less useless, because time outs must be very
-     exceptional for this (and any other) scheme to make sense.
-  Hard to debug code in the SR side, because of other higher priorities during beam time

##  The L3 Monitoring Server:

-  Progress/Problems with Linux nodes
- We had, so far, none of the problems seen with NT nodes :
-      - no time outs
-      - no corrupted data
- We have implemented the feature that the server can deal
- with several processes per node. So far, we had no problems.
- But we have not yet tested the system at full load, with :
-   - Lots of nodes  >> 10  (expected  ~100 nodes, 2 processes per
-                                                     node)
-   - Lot of information travelling

- L3 Nodes

- L3 Nodes

- L3 Nodes

- L3 Nodes

- L3 Nodes

- L3 Nodes

- Taking advantage of the modular design, we may consider the possibilty of :

## L3MonChunk:

-   map<int l2bit , map< string l3name, Stat> > _map;     //  L3ChunkStatMap
-   vector<int > _time;                                                        //  Time Histogram
-   map<int run#, ClientData *> _clientData
-                                        // holds all client information per run #:
-                                        //L1<->L2 map. L2 active bits mask
-                                        // and L3 #<->name)
-   map<int l2bit, string name > _l2map;                    // L2 #<->name map (all)
-   map<string name, l3ToolStats *>    _tool;              // ToolStatMap
-   map[<string name , l3FilterStats *>_filter;             //FilterStatMap
-   map<int l2bit, map<string l3name, LumStat> >  _lum_old;           // L3LumStatMap
-   map<int l2bit, map<string l3name, LumStat> >  _lum_old_save;   // L3LumStatMap

- L3MonChunk:

## L3TEle

- diem_cal

- L3FJet
- (Jet10)

- (Ele_Loose)

- L3TJet
- (Jet_10)

- L3FMEt
- (calmet_)

- Ele1

- el_jet_met

- Execution tree

- L2 bits

- L3 scripts

- L3 filters

- Tools

- L3FEle
- (ele2)

- L3FInvMass
-    (inv_1)

- .
- .
- .

- .
- .
- .

- .
- .
- .

- (ele1)

- L3FEle
- (ele1)

## Tools ready post-shutdown

_**Conclusion**_

**Tools ready post-shutdown**

**LTJet**
**LTEle**  w/emfrac & isolation cuts available
-              w/shower shape being tuned
**L3TMuoLocal****	****     *****pending certification***
**MET****	****	****               *****pending certification***
**SMT**-only Tracker    ***pending certification***

**Additional tools ready by New Year**

**L3TMuon****	****     *****w/ *****trackmatch, SCINT, MTC**
**CPS****	****	****	****  *****available with hardware***
**GlobalTracker                       *****for***
**L3TCFTTracker****	****	*****online testing***