1. 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 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

2. 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

3. 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

4. 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

5. 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?