Status of PRS/Muon Activities D. Acosta University of Florida Work toward the “June” HLT milestones US analysis environment

US CMS S&C and Physics Meeting, July 26, 2002Darin Acosta2 HLT Milestones The June HLT milestones are: è Complete HLT selection for high-lumi scenario è HLT results on B physics è CPU analysis for high lumi selection è Repeat on line selection for low-lumi Must have results in DAQ TDR by September! We don’t have these results yet, but the current status and L1 results were reported at the June CMS Week è HLT Muon code had severe crashes, infinite loops, and memory leaks that prohibited collecting any statistics on our HLT algorithms è After monumental debugging effort, crashes traced to incorrect use of “ReferenceCounted” objects p User must never delete, even if performed new! è In L1 results, rate spike appeared at  =1.6 p New holes in geometry? è Problems were “fixed” for ORCA_6_2_0 release

US CMS S&C and Physics Meeting, July 26, 2002Darin Acosta3 L1 CSC Rate Spike è Contributes ~1 kHz to L1 rate è Spike occurs in  and  ! è Region of crack between barrel/endcap è Traced to ambiguity in p T assignment for low p T muons (or punch-through) è Fixed in CSC Track-Finder (but not sure why this is a problem only now) 

US CMS S&C and Physics Meeting, July 26, 2002Darin Acosta4 Not out of the woods… Tony reports that the Muon RootTreeMaker has a massive memory leak (200–500kB/event) è Analysis stopped at CERN (batch nodes were dying) è But muon HLT code alone was shown to have a leak of “only” 16 kB/event when released p So is it because events have more occupancy with pile-up, or is it because of jet/tau/pixel code? è Still under investigation p At FNAL, I find a leak of 800 kB/event for Z , and it is lumi dependent (600 kB/event for 2*10 33 ) p Nicola Amapane promises some results(fix?) this evening Moreover, the DT reconstruction is known to have some deficiencies So we have a two-fold plan: è Continue with current Root Tree production at remote sites to get us a set of baseline results for HLT milestone p We already had Pt1, Pt10, and Pt4 (low lumi) done before CERN shut down. p Can Fermilab help? Run ~1000 short jobs on PT4 if leak not fixed è Push hard to get new HLT reconstruction code written to solve remaining problems in time for September deadline

US CMS S&C and Physics Meeting, July 26, 2002Darin Acosta5 Status of New Reconstruction Code Stefano Lacaprara has authored a new version of DT reconstruction code è Corrects some naïve handling of the DT hits, incorrect pulls, new code organization,… p Turns out DT reconstruction must know drift velocity to ~1% This code has been examined (some bugs fixed) and cleaned up by Bart Van de Vyver (and also by Norbert and Nicola) Aiming to get new results in August, hopefully with new reconstruction code

US CMS S&C and Physics Meeting, July 26, 2002Darin Acosta6 Muon Analysis at Fermilab Request made to get the Muon Federations copied from CERN è Pt4 single muon sample at highest priority p Shafqat predicts copied by Monday è Pt1, Pt10, W, Z, and t-tbar to follow è Z  (on-peak and above) already available Root Trees will be copied as well, when available US users thus have at least one local choice for an analysis center, in addition to CERN Mechanism to obtain FNAL visitor id and computer accounts remotely works well (Thanks Hans…) When Pt4 sample ready, PRS/Muon group is interested in running large number of RootTreeMaker jobs at FNAL è INFN still trying to copy PT4 tracker digis (0.7TB)

US CMS S&C and Physics Meeting, July 26, 2002Darin Acosta7 Florida Prototype Tier-2 Center Currently host the Z  samples in Florida è but only for local accounts, I think, at the moment. Eventually should be accessible world-wide. Limited by available disk space è Several TB of RAID ordered Problematic analysis environment è Although the Production environment is working quite well with DAR distributions, the analysis environment (where users can compile and run jobs) is a little unstable p Some difficulties building code in ORCA6, perhaps traced to using RH6.2 vs. RH6.1 (loader version) è Need a more standard way to set up analysis environment p I think INFN also had some initial difficulties getting ORCA_6_2_0 installed and working Should be solved once key people come back from vacation

US CMS S&C and Physics Meeting, July 26, 2002Darin Acosta8 Side Note… For better or worse, we are working with a complex set of software for CMS è Definitely not easy for newcomers to contribute to development or to debugging (or to create a DB) p Case in point: how can a summer student plug a new L2 module into ORCA? è Many layers to ORCA software, difficult to navigate, little documentation of “common” classes p Sometimes counterintuitive rules must be followed è Complexity probably partly intrinsic to ORCA/COBRA, and partly due to inexperienced physicists working in this environment That being the case, we MUST have professional tools for development and debugging è Must be able to debug and profile the code, check for memory leaks, corruption, etc. è This is standard for CDF, and reliability of production code has increased dramatically è Requires analysis workstations with enough memory to handle these tools Should start defining a set of validation plots to show problems early in production