Trigger simulation readiness review 2005.8.1 (these are quite rough stream-of-consciousness notes) present: Eric, Su Dong, Selina, Rainer, Valerie, Jamie (phone), Stephen G.; and committee: Swagato, David L., gpdf, Steven R. (phone) General notes: - So far Run 5 testing has not included background frames. * Definitely needs to be done. - Independent re-implementation of algorithms in C++ chosen over simulation of actual as-built VHDL code, primarily because the latter would have required very substantial investment in simulating very specific details of the hardware. * This raises the importance of board-level testing (in gpdf's opinion, at least). Would like table summarizing what board-level testing has been done on the new simulation code for each of the old and new trigger components. - Project has moved far enough along that testing is being done out of the nightlies using an alternative Moose build. Increases confidence in quality of testing. Good! - New/old simulation switch keyed off of presence of L1 lines associated with ZPD. Exactly algorithm for the switch was not completely clear. Some exotic cases (taking data from a trigger system without using it to trigger) may not be handled correctly. * Need algorithm laid out precisely for committee. * Would like enumeration of all point in the simulation that are controlled by the resulting Boolean. - Some concern about residual hard-wired parameters controlled by TCL switches. * Would like a complete enumeration of them, specifically w.r.t. to parameters that could change in the future. GLT: - Many figures unlabeled or mislabeled. Inconsistent use of colors here and throughout all the presentations unnecessarily obscures the comparisons being made. - Board-level testing done using prototype simulation code, not the final code in CVS. (? not certain of this) - Algorithm test framework not even easily commited to releases because of conflicts with L1*Odf code. Test code apparently being kept in NFS. * Must be made to fit the release structure. Minimum short-term step before that is to move working code base to AFS so that it is properly backed up. - Presentations did not explicitly cover validation of simulation of GLT "end game" (which attempts to sharpen up latency jitter by combining information from multiple sources). * Would like to see some comment on this. - Some dramatic timing discrepancies with data and the old simulation noted. Suspect EMT and/or timing mismatches between the stages of the L1 trigger simulation. Possible that improved accuracy of the GLT simulation is revealing previously hidden or compensated errors in the EMT simulation (which is being carried forward from before). * Need update on pursuit of these problems. - Concern that EMT simulation is inadequately supported. EMT work that is arising appears to be falling to DCZ team. TSF: - gpdf, at least, didn't understand how the common interface to 5-bit and 6-bit fine phi information works in practice. - Problem with "hitmaker" code - fails dramatically when background hits are introduced. Less correct algorithm, similar to that used in trgDC, seems to work more robustly, but does fail to capture some features. * Would like update on the hitmaker, but it does not seem essential to get this right before going into larger scale validation tests, perhaps even production. BLT: - "BLT dPhi match" asymmetry is puzzling; uncertain exactly what algorithm is used to calculate it. (Simulations and data do match, though.) * Would like full 2x2 matrix of plots for {trgDC-vs-L1Sim,data-vs-L1Sim}x {A tracks, B tracks} instead of just the diagonal. Threefold comparisons (data,trgDC,L1Sim) overlaid would typically be more useful still. - "BLT dPhi" and "BLT dPhi match" for B-tracks on hadronic events show some systematic differences between data and L1Sim. Log scale makes it difficult to evaluate importance. - In general, data/MC agreement seems improved over trgDC - congratulations. - Some anomalies seen in efficiency vs. tandip (data shows a drop around tandip = {-1,+0.5}). Not modeled in either simulation. * Can this be confirmed to be related to the lower average value for charge for perpendicular tracks? * TSF -> BLT data path not directly validated against teststand - Historical issue: full story of overrides ("masks") for disabled DCH SL5/6 regions in early running not represented in database. Only one set of overrides presently simulated. PTD: - Timing shift of O(1 tick) vs. data (was even worse in trgDC). - Significant bugs corrected vs. trgDC. Visible improvement in p_t efficiency curves. Still significantly different from data, though. - (?) A remaining known problem with the phi alignment is not being simulated. - No board-level simulation attempted. - Ability to reproduce PTD LUTs has been lost over time. Simulation is not based on LUT anyway, but on a logical recreation of the algorithm that the LUTs are supposed to be implementing. * Somewhat uncomfortable with combination of last two points, plus large shift from trgDC behavior. Perhaps not enough breadth of evidence that simulation is right? Corner cases not covered by the basic comparisons that have been done? * Minimal suggestion: redo plots on p. 7 with > 10x statistics; ideally would like to be able to see ~1% effects in efficiency vs. angle -- completely invisible with statistics now plotted. * Perhaps examination of matching between A (BLT) and A' (PTD) tracks would provide additional independent test? ZPD: - Significant discrepancies on p. 5/9 in data vs. MC, in timing (6 ticks) and spatial distributions. Spatial distributions may be fixed by mixing in background. * Need tests with background. * Need higher statistics in efficiency plots on p. 7/9. - Board level tests not repeated with final code. Should do. Other accumulated thoughts: * Need tests of Level 3 quantities: lines (which depend on Level 1 lines) and track parameters, efficiency (which depend on TSF segments); Runs 1-4 and Run 5. * [cryptic note to myself that there was a case where we needed to know whether some distribution after BGFMultiHadron cut included effects of Level 1 -- can anyone remember what this was about?] * More extensive physics-level validation needed. (C.f. experience with EMC recalibration.) Summary and deployment issues: - Overall, looks good. Plausible that end is in sight and new simulation can be used for Run 5 as well as for Runs 1-4. * Suggest that hot issues from review, especially latency distribution problems, simulation of Run 5 including background, be resolved over succeeding week. * Then can move to building a release, generating some pre-production Run 5 samples, presumably a mix of signal and generic. This is all throwaway, because final Run5/R18 constants not available (reprocessing hasn't started), so it should start ASAP. It will be useful to others, too. * Switch of SP8 for Runs 1-4 to L1Sim requires a substantial validation. Would like to attempt to complete it in time to be able to use L1Sim for Run 4. Need to define the validation procedure (action item for computing, physics group). How many events of how many samples are needed? Who will do the testing? Need to motivate the switch for Runs 1-4 for users. Will need some good examples of benefits.