SVAC Configuration Verification What did we check? Numbers in the csv matrix that we understood, were compared to values from snapshot files and rcReport.out Values of registers we considered the most relevant for offline data analysis were given highest priority (see next slide) Cosmic ray runs were first in the list Look at all Digi and recon Distributions in the SVAC reports Procedures? We produced SVAC configuration reports from reference files delivered by subsystems Used those from email from Hiro and Eric Had Martin come to our office to look at the trigger information Printed reports from actual runs and compared by hand Our system was designed to provide feedback for data analysis within a week time frame However it became part of the integration sequence and we had to use it to provide answers within a few hours Of course, it was not smooth

Registers we care (today) for the offline data analysis TEM Status  Zero Suppression ON/OFF, TEM diagnostics ON/OFF Detector Registers TKR GTRC splits TKR GTFE thresholds in DAC units for ranges 0 and 1 CAL GCFE thresholds in DAC units (LAC, FLE, FHE) CAL Readout range selector discriminator CAL DAC for DC reference CAL delays 1,2,3 Trigger and Timing Registers (GEM, GLT) Delay from CAL trigger discriminator to TEM trigger primitive formation Delay from TKR trigger discriminator to TEM trigger primitive formation Stretch width of CAL trigger primitive Hold trigger primitive for TEM diagnostic latching of CAL trigger primitive Hold trigger primitive for TEM diagnostic latching of TKR trigger primitive Width of trigger window in GEM Delays from trigger TACK to shaper hold for CAL and TKR  

Data Quality Plots Go to the Runs database Query on Test ID: 1/1 Completion Status: PASSED Duration: > 1000 Look at Config report and digi and recon reports Currently we are updating the reports based on the results from these runs Comments are welcome Please come to our Friday meetings if you want to participate

Issues The current verification scheme can be improved What to do to improve and who will check configurations for 2 tower tests? In case you still wants us to do it, we have a shopping list Note that SAS/pipeline then becomes then part of the integration sequence and this is a change in plans and the impact needs to be assessed To improve the process we recommend Review of matrix prior to tests, to ensure values are correct For example, trigger timing wasn’t (not a big deal but it should be right) Delivery of reference files from (CAL, TKR and TRIG) for both towers with description of contents 3 days in advance (CAL/TKR), 1 day in advance (trigger) Get a list of additional registers to be checked and their reference values CAL send us requests for config_0 and config_1 that we are trying to accommodate n the next release of our code (ASAP) Produce a general tool to parse the snapshot file Unoftunately neither online or SVAC could od that, better if ISOC does it The automation of the verification process could be done but SVAC priority is to analyze data ASAP so that we can provide feedback to the 2 tower tests Can’t promise that will happen for 2 tower tests, but could try for the LAT tests

What did we learn? Runs checked (took 2-3 hours to go through data quality reports) 1/1,2/3,2/6,2/7,3/1,3/2,7/1,4/1,8/6,4/2,4/3,5/3 Runs to be checked which are already available 5/6,5/7,8/8/,4/4/,B/1 there are still 15 runs to be taken What next? A presentation in IA Friday meetings Prepare a list of run numbers and test IDs Show a summary of plots Present a list of questions for which we do not have an answer yet these will lead to data analysis tasks for the LAT collaborators Hopefully we will be able to provide feedback to the 2 tower tests What is deadline for that?