BGS Data Analysis Calibration NonLinearity Correction Heather L
BGS Data Analysis, Calibration & Non-Linearity Correction Heather L. Crawford Nuclear Science Division Lawrence Berkeley National Laboratory GRETINA Software Working Group Meeting 2012 – September 21, 2012
OUTLINE • Data Analysis at the BGS ▫ ▫ Set-up of the two data acquisitions Merging BGS + GRETINA Data analysis – general scheme Optimizing raw data analysis • Calibration ▫ Approaches to calibration of 1120 channels ▫ Tools available at present • Non-linearity corrections ▫ Measurement of the ADC non-linearity ▫ Non-linearity correction as currently implemented 2
COMMISSIONING RUNS @BGS 3 A large amount of analysis code development went hand-in-hand with the engineering runs, and then the commissioning runs at LBNL. Data integrity checks and corrections were developed, calibration schemes were refined, and analysis options diversified. Some of what was done is now (happily) obsolete, as the system performance has improved, some software solutions have been integrated into the system, and some work is still ongoing.
4 GRETINA VS. BGS DAQ GRETINA DAQ • Data acquisition including 29 IOCs, run via EPICS interface, on a cluster of computing • 100% digital electronics, system based on time-stamping scheme • Global event builder time orders data coming from each IOC, to create a unified data stream BGS DAQ • Analog data acquisition run using RIO 2, circa ~1999 • Network broadcasting of data was not achieved easily • System based on triggered full-event readout
5 COMBINING DATA AT THE BGS • General scheme for merging data within a GRETINA + X experiment depends on time-stamping • System is built to include outside data into the global event builder, which is incorporated with a different global header ID type, based on the value of a synchronized timestamp GRETINA TRIGGER SYSTEM BGS FP TRIGGER SCALER GRETINA 50 MHZ CLOCK GRETINA IMP SYNC 1. BGS DAQ started 2. GRETINA DAQ started Always required 3. GRETINA DAQ initialization syncs clock and sends imp sync to BGS 4. BGS scaler clears, and trigger inhibit is released
COMBINING DATA AT THE BGS • Data at the BGS was taken with synchronized timestamps, but transmission of data to the GRETINA global event builder was not achieved • Solution: simple software to merge two independent files from the separate acquisitions ▫ C++ code was written, which rebuilt BGS events, decoded the timestamp, and created a global event-style header for each BGS event, and merged with GRETINA data, based on timestamp values ▫ Code is 100% blind to the type of GRETINA data, using only the global headers to sort ▫ Extension has been written to merge any two arbitrary files, provided they contain data with global event headers 6
BGS DATA ANALYSIS - OVERVIEW • GRETINA: ▫ Analysis of raw (mode 3) data format, including building complete events out of individual channel events in the data stream ▫ Trigger was selective enough to more or less provide 254 Nocorrelated gamma-rays without analyzing BGS data ▫ Essentially no decomposed/tracked data was looked at online during the BGS experiments • BGS: ▫ Correlation analysis for evaporation residues (EVRs) with subsequent isomer/alpha decays within the 3 DSSDs of the focal plane Two approaches were taken: analyze BGS + GRETINA together in one code, or analyze each individually, and use TS lists of ‘interesting’ BGS events in GRETINA codes to filter data. 7
ROOT CODE ARCHITECTURE • ROOT analysis provides capabilities for full GRETINA analysis, as well as complete BGS (and S 800) analysis • Code is based on global header information – ▫ Events are built by grouping global headers within a given time window (i. e. 10 us) – there are no event delineators in the data ▫ Data is handled based on the type given in the global header, making it simple to add auxiliary devices • ROOT trees allow easy gating on auxiliary detector information to look at GRETINA, etc. – for BGS analysis, multiple trees based on BGS flags sped up spectrum generation, etc. 8
BGS DATA ANALYSIS – OPTIMIZING RAW DATA • Data analysis at the BGS had a different focus than the analysis here at MSU, or at ANL will have – effort was on optimizing the raw data, identifying and solving problems • Diagnostic counters were critical: ▫ 40 channels present / crystal (TTCS data taking) ▫ All channels with a net energy deposition reported it (simple energy filters checked this for every channel event) – with what frequency was this not true? ▫ Does the pile-up flag really tell you about pile-ups on the waveforms? What fraction of events are piled up? CC and segments? ▫ Is the data really time-stamped ordered? • Focus on the use of segment sum energies (as a result of the high CC rate) led to it’s own set of considerations 9
BGS DATA ANALYSIS – SEGMENT SUMS • High CC rates are one instance where using segment sums should provide an advantage in energy resolution (segments won’t be piled-up) • Not a simple thing to do in practice: ▫ Segment energy calibrations, especially with nonlinearity of GRETINA ADCs are non-trivial ▫ Segment integral cross-talk!!! ▫ Missing segment energies from the FPGA ▫ Actual detector geometry causing charge loss? 10
Segment A WHY SEGMENT SUMS ARE HARD δAB Segment B 11 • Gate on CC, look at individual pairs – fit 2 D plots • Intercept along y-axis gives δBA (effect on segment B due to segment A firing), intercept along x-axis gives δAB ** Requires a good segment energy calibration
BGS DATA ANALYSIS – WHERE ARE WE? • While the majority of BGS data analysis effort has not directly translated to the analysis on-going at MSU, it did have a large impact on fixes made to the data acquisition, etc. • Techniques for calibration and correction important to segment summing will be important in future physics • campaigns, and • continuing work will • refine the analysis using • segment sums 12
GRETINA CALIBRATION All told, 7 GRETINA quads provides 1120 electronics channels which need to be calibrated – 112 CC and 1008 segments Considerations: • Calibration of all channels is required for decomposition, so even if you’re not going to use segment energies, you need to calibrate the segments • If you will use segment energies (i. e. at the BGS), you need a good segment calibration – both energy calibrations and cross-talk corrections will be critical for summing segments with good resolution 13
GRETINA CENTRAL CONTACT CALIBRATION • Central contact calibrations are analogous to any other HPGe detector – find and fit peaks. • Peak finding and fitting for energy calibrations routines exist within the ROOT framework, taking advantage of built-in ROOT functions to identify peaks, etc. • Macros were written to give flexibility in the evaluation of peak fits, if desired, and to characterize the detectors in terms of resolution, etc. easily 14
GRETINA SEGMENT CALIBRATION • Segment energy calibrations can be done with an intense 60 Co source (or a really long time), but this is a quite limited calibration, at least for rear segments • As an alternative to a segment calibration based on peak-fitting, segment multiplicity 1 events can provide a method to calibrate • During the BGS runs, this method provided a superior low-energy calibration, and a first segment non-linearity correction 15
16 NON-LINEARITY WOES • Non-linearity of the ADC manifests both in calibration residuals and energy vs. baseline plots when running at high rates • At the BGS, the larger problem was the loss of resolution due to the high rate, and the difficulty in segment summing with poor segment calibrations • At MSU, the energy calibration is a greater concern Baseline of Pulse (ADC units) One of the much-discussed problems identified in the commissioning runs at the BGS was the non-linearity of the GRETINA ADCs. Energy (a. u. )
17 ATTACKING THE NON-LINEARITY Hardware • Linearity of the CC was improved by hardware modifications to change 2 CC/crystal to full ranges of 2. 5 and 5 Me. V • Each crystal now provides 4 CC gains: 2. 5, 5, 10 and 30 Me. V full range, with 2. 5 and 5 Me. V ranges showing linear behaviour Software • To keep the 10 Me. V full range of the ADCs, a software correction was developed • Method required measurement of the absolute non-linearity of the 1120 electronics channels, in order to provide the data necessary for an event-by-event software correction – two channels were calibrated absolutely, and all channels were calibrated relative to these INL units (a. u. ) D. Radford ADC units (a. u. )
ABSOLUTE NON-LINEARITY MEASUREMENT Triangular wave 0. 8 V up/down in 0. 1 ms period Delay Amp Q 1 A 1 #4 Digitizer Module ch 0 + ORTEC 427 A ch 2 + Delay Amp ORTEC 427 A Slow ramp -2 -> +2 V, 1. 5 s period D. Radford ch 0 ch 2 - external trigger from triangular wave generator 18
ADC value ABSOLUTE NON-LINEARITY MEASUREMENT Digitized waveform d. V = constant dt = fixed difference in time Time (10 ns samples) D. Radford 19 External trigger provides a reference time at a fixed point in the faster waveform, so each trace should have the same nonlinearity contribution from the WFG. The slow ramp effectively moves the fast waveform over the whole range of the ADC. Extract d. ADC/dt for the fast wave at all starting values of the ADC – because d. V is constant, this is a measure of the ADC non-linearity.
20 Data is taken with a common trigger, so both digitizer channels observe the same waveform. Relative non-linearity is easily extracted, and the reference non-linearity can then be subtracted. Triangular wave Board 1 D. Radford Reference chs Relative non-linearity measurement are much simpler, simply use a triangular wave into the reference channel + unknown channel to be characterized. Channels to be measured RELATIVE INTEGRAL NON-LINEARITY MEASUREMENTS Board 2
NON-LINEARITY SOFTWARE CORRECTION 21 Following the absolute non-linearity measurements, an offline correction algorithm was developed by D. Radford. This algorithm has been incorporated into the GRETINA pre-processor, and currently corrects the linearity of the 10 Me. V CC for the campaign at NSCL. Correction Basics: • Two sums are calculated for each waveform: baseline + flattop • ‘Resting baseline’ is calculated by fitting the baseline, and iteratively improved with each trace processed • Calculation is corrected using these sums, the resting baseline, and measured INL
ONLINE NON-LINEARITY CORRECTION 22 Non-linearity correction has shown good results in calibrations, and no indication of problems during in-beam runs has been observed.
23 Thank you!
24
25 GRETINA STAND-ALONE GRETINA IOC … x 29 Timestamped @ 50 MHz GRETINA Global Event Builder (GEB) TS orders Raw data (mode 3) TS ordered, raw data including waveforms TS orders, builds 40 channel crystal events, runs decomposition on GRETINA cluster Decomposed data (mode 2) TS ordered, decomposed to x, y, z, e
26 GRETINA + S 800 The interaction point between the S 800 DAQ and GRETINA is at the GEB – S 800 events are sent over the network, received and dealt with by the GRETINA GEB. The GEB relies on ‘global headers’ with 3 pieces of information in 16 words: Type (i. e. 1 = Decomp GRETINA, 2 = Raw GRETINA, etc. ) Timestamp (50 MHz) Length of data to follow (in bytes) GRETINA IOCs TS orders, builds 40 channel crystal events, runs decomposition on GRETINA cluster TS orders Raw data (mode 3) TS ordered, raw data including waveforms GRETINA ONLY S 800 CAMAC + VME Readout Decomposed data (mode 2) TS ordered, decomposed to x, y, z, e GRETINA + S 800 Timestamped @ 12. 5 MHz, using GRETINA clock downscaled by 4
‘STANDARD RUNNING’: OUTPUT FILES In the currently adopted ‘standard’ running mode at NSCL, two output files are generated: 1. “Global. Raw. dat”: contains time-ordered GRETINA raw channel events only, including a 16 -word global header for each unique timestamp struct Geb { int 32_t type; int 32_t length; /* length of payload in bytes following the header */ int 64_t timestamp; } Raw (Mode 3) data consists of a header, followed by trace information: 27
‘STANDARD RUNNING’: OUTPUT FILES 2. Global. dat”: contains time-ordered GRETINA Decomposed crystal events, GRETINA Bank 29 raw channel events, and S 800 events, all including the 16 -word global headers struct crys_intpts { int type; /* defined as abcd 5678 */ int crystal_id; int num; /* # of int pts from decomp, or # of nets on decomp error */ float tot_e; /* dnl corrected */ int core_e[4]; /* 4 raw core energies from FPGA filter (no shift) */ long int timestamp; long trig_time; /* not yet impl */ float t 0; float cfd; float chisq; float norm_chisq; float baseline; float prestep; /* avg trace value before step */ float poststep; /* avg trace value following step */ int pad; /* non-0 on decomp error, value gives error type */ struct { float x, y, z, e; /* here e refers to the fraction */ int seg; /* segment hit */ float seg_ener; /* energy of hit segment */ } intpts[MAX_INTPTS]; }; 28
ONLINE DAQ MONITORING - GRETINA 29 Effort has been put in to distill the large amount of DAQ information available in EPICS to the key information, and consolidate this onto one meaningful alarm page.
ONLINE DATA INTEGRITY MONITORING Online data monitoring at NSCL is done via the established NSCL Spec. Tcl program, which has been modified to sort the combined S 800 + GRETINA (Mode 2) data. Thanks to Dirk Weisshaar for writing the Spec. Tcl code, and for the screenshots. 30
DATA ANALYSIS Online: Online data analysis at NSCL is essentially restricted to Spec. Tcl. All other software analyzes files written to disk. Offline: At present, there is no officially supported offline analysis package for GRETINA data, however there are several options to start users off. 1. Spec. Tcl – the same code used for online analysis can be used offline. There are possibilities using Spec. Tcl to create intermediate output files, with S 800 physics data processed into a simplified format, and GRETINA left intact. NSCL / Dirk Weisshaar 2. C unpackers – for GRETINA only, there exist straightforward C codes which typically fill Rad. Ware spectra. These are an excellent starting point for a user who prefers to stay away from Spec. Tcl/ROOT. Paul Fallon / David Radford 3. ROOT – at present, two independent ROOT analysis codes exist, which analyze both S 800 + GRETINA (Mode 2/Mode 3). One code has the possibility of tracking included. Heather Crawford / Kathrin Wimmer (code available at http: //www. nscl. msu. edu/~wimmer/software. php -- password by emailing Kathrin at wimme 1 k@cmich. edu) 31
DATA ANALYSIS –OFFLINE WITH ROOT analysis options both include S 800 + GRETINA, and include much of the necessary code for S 800 corrections, etc. Data can be sorted into any combination of histograms and/or ROOT tree structures, allowing gating without rescanning of data. 32
DATA ANALYSIS –TRACKING Tracking is currently not being done online, but rather as a part of the offline data analysis. The supported tracking code comes from Torben Lauritsen, and uses ROOT to generate histograms, and write a tracked output file, which builds events and returns GRETINA in Mode 1, or tracked format. Eg At present, Torben’s code can handle BGS data, and enhancements for S 800 analysis (with S 800 physics) are underway. http: //www. phy. anl. gov/gretina 33
- Slides: 33