DØ Level 3
Algorithms Meeting: 20th November 2002 in the Farside
Talks
-
Results from L3MEt online: Markus Klute.
-
L3MEt filters running online since global_CMT-9.30. Running without Nada.
Rejections OK and stable run-by-run. No bad runs so far.
Cross check on events triggered with EM_HI_SH shows MEt-based
filtering working OK.
-
Development of additional triggers for top: based on lepton+MEt+jets.
-
MU_JT15_MET10: a 10 GeV L3MEt and 15 GeV L3Jet requirement would give
a rejection 8.1 wrt L1 mu+jet trigger.
-
EM15_2JT15_MET10: adding a 10 GeV L3MEt requirement would give an
extra rejection of 2.7 wrt the current trigger EM15_2JT15.
-
Study of Coarse Hadronic contributions
to L3MEt: Joe Steele.
With CH the missing ET is broader (even in good runs).
In physics with genuine missing ET the rms should be approximately the
same with or without CH.
Suggests we should ignore CH.
Could switch off CH with .rcp and Joe will study this.
-
Comparator studies: Han Do.
-
Differences at 10E-6 level when looking at .root files.
Probably a debug / maxopt difference.
-
Differences are at machine precision level when looking at DST output,
except for four events with a large difference. This seems
inconsistent with Yann's results.
Action item: Yann and Han will take a look at
these events.
Discussion Items
Jon Hays introduced a number of items:
-
Since p13 the TMB depends on L3TMB which depends on L3 physics_results.
This introduces dependencies on a huge number of extra libraries for a
TMB analysis job. We need to break these dependencies.
Jon's proposal, which was widely accepted, is to move physics_results
out of tool classes. We need to make a new package for each tool that
produces physics results. A TMB analysis job would then have to
depend only on these packages and not the entire code that produced
the L3 results. (Is this the approach that is being adopted by
offline RECO?)
-
Inclusive streaming is switched off by default, but can be switched on
by trigger list.
This will be tested in the next week.
-
Error stream:
How do we handle errors and how should we handle errors?
Currently if one tool returns with an error, the rest of the
processing occurs as if nothing untoward had happened:
the other tools process the data and the event is triggered if appropriate.
Adding an inclusive monitor stream, to which all events that produced
a processing error would be written, would be a conservative option.
-
Scriptrunner wrongly processed some events, because it had failed to
be proprerly re-initialized when nodes had been returned to the global
after having been used for SDAQ during physics running. No events
have been lost, but some L3 triggers fired on bits that were actually
rejected by L2. The best way to fix the data offline is being discussed.
-
There are a few places where we should tighten up our
testing/certification procedures.
Action item: Terry Wyatt will present a summary/proposal at next week's meeting.
Scribe: Terry Wyatt.