August 8th, 2005
This is follow-up information for the L1Sim Readiness Review held August 1st, 2005.
Room: Redwood C/D
Teleconference: +1-510-665-5437, code 1574
One of the key outstanding problems is the L1A timing spread shown here. A more detailed page showing an investigation into the problem is here, but probably isn't relevant for today.
The L1A time is different by about 134 ns (one clk8 period) depending upon the clk4-clk8 phase difference in the FcsClock. The bulk of this problem has been tracked down to the L1EmtSim/L1EmtGltConvertor which reformats the L1EmtSimModule array output into timebuffers for the GLT.
The offending code was:
int firstClk8(clock->tickAtBx(5,emtgdigi->bxAtFirstSample()
+ firstNonZeroTick));
And has been fixed in L1EmtSim V00-04-06 to be:
int firstClk8(clock->tickAtBx(5,emtgdigi->bxAtFirstSample())
+ firstNonZeroTick);
In the old code, the firstNonZeroTick, which is a clk8 pointer into the EMT arrays usually set to about 75, is interpreted as a number of beam crossings. Essentially the extra clk8 offset from the true event time was being ignored, and the time buffer was constructed with a fixed offset to the true MC event time. This explains the phase difference.
This wasn't noticed because the EMT timing is adjusted emperically at the GLT inputs to align with other data. In trgDC, the entire array was passed, with the first array tick at large negative values, which lead to very large latencies added at the EMT input (ie: 88 clk8 ticks). In the new simulation, the latency was emperically adjusted to about the same value, which seemed to make sense.
After the fix, the latencies were re-adjusted and now match much closer the other inputs (as they should). The May2004 and Apr2005 (with background frames) MC samples have been regenerated and plots with this new data are available here. See the t0 plot and the input timing. It looks like we still need to slightly tweak the latencies to get everything to line up correctly.
There are still places in the GLT simulation, parts of which has been copied directly from trgDC, where questionable things are being done to the timing. Code like the following in the L1GltSim/L1GltSelectTrigger is not good:
int clock15 = 2*(iTick8);
In the current code, it is being "corrected" by hand later in L1FctSim/L1FctPrescaler:
const int Clk15_Tick_Corr = ( fcsClock->clkOffset(5) <= -16 ) ? -1 : 0;
const int timeZeroOffset = Latency_Fct_Total - Clk15_Tick_Corr;
Clearly this should be fixed to avoid confusion in the future. We propose to do this in an adiabatic way which will be unlikely to change the core algorithm (at least not by much).
The run 5 comparisions, particularly the ZPD comparision plots, previously did not have background frames overlayed, which made comparision difficult. This has now been fixed (at least for Apr2005) and the new MC samples include this. Plots for tsf and zpd are available. Things look much more reasonable, including the TSF efficiency dips in the center of the detector, although the ZPD efficiency still doesn't match exactly.
On Monday, some of the L1 line efficiency plots were questioned, particularly direct comparisions with trgDC for 2004 data. I have remade these with the new MC samples (although not the TSF window) and the new simulation seems to match much better. Comparision of simulation with data for 2004 and 2005 (hadrons) show similar discrepancies. More plots are here.
I have made some comparisions of L3 filter rates using Rainer's compareFilters script for the 2004 trgDC and new L1Sim runs. This still may not be exactly what we want. Differences for mu, tau and bbbar are shown (trgDC vs new L1Sim). The Bhabha samples were generated with different numbers of events, making comparision with this script difficult.
It was found after the review on Monday that the DAQ window had NOT been applied to the TSF DAQ data showed by Jamie. This potentially could effect the monitoring plots and the L3 tracking. Further investigation showed that in trgDC the window had also been removed, likely due to the fact that the TSF tick distribution was mangled in data and hence did not make much sense. One nasty feature, which we may want to change, is that the tick in the DAQ digi is filled with code like the following:
_tickBits = (tick & 0x000f) << 28;
This matches what is done in the data, but for simulation if a larger value is passed, the last four bits will be masked off and all DAQ data will end up appearing to be in the timing window. If the window is properly applied, this won't happen, but if not you will get a kind of "background" from out-of-time digis. This effects monitoring, and potentially the L3 tracking.
The mis-labelled figures in the GLT presentation have been corrected.
Last updated: