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

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

3. 3 C OMMISSIONING R UNS @ BGS 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 DAQ 4 GRETINA VS. BGS DAQ BGS DAQ Data acquisition including 29 IOCs, run via EPICS interface, on a cluster of computing 100% digital electronics, system based on time-stamping scheme Analog data acquisition run using RIO2, circa ~1999 Network broadcasting of data was not achieved easily System based on triggered full-event readout Global event builder time orders data coming from each IOC, to create a unified data stream

5. 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 5 C OMBINING D ATA AT THE BGS S CALER GRETINA T RIGGER S YSTEM GRETINA 50 MH Z C LOCK GRETINA I MP S YNC BGS FP T RIGGER Always required

6. 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 C OMBINING D ATA AT THE BGS

7. GRETINA: ▫ Analysis of raw (mode3) 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 No- correlated 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 7 BGS D ATA A NALYSIS - O VERVIEW 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.

8. ROOT analysis provides capabilities for full GRETINA analysis, as well as complete BGS (and S800) analysis Code is based on global header information – ▫ Events are built by grouping global headers within a given time window (i.e. 10us) – 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 ROOT C ODE A RCHITECTURE

9. 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 D ATA A NALYSIS – O PTIMIZING R AW D ATA

10. 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 non- linearity of GRETINA ADCs are non-trivial ▫ Segment integral cross-talk!!! ▫ Missing segment energies from the FPGA ▫ Actual detector geometry causing charge loss? 10 BGS D ATA A NALYSIS – S EGMENT S UMS

11. 11 W HY S EGMENT S UMS A RE H ARD Gate on CC, look at individual pairs – fit 2D 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 Segment A Segment B δ AB

12. 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 BGS D ATA A NALYSIS – W HERE ARE W E ?

13. 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 C ALIBRATION

14. 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 C ENTRAL C ONTACT C ALIBRATION

15. 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 GRETINA S EGMENT C ALIBRATION

16. 16 N ON -L INEARITY W OES 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.) Baseline of Pulse (ADC units) 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

17. A TTACKING THE N ON -L INEARITY Hardware Linearity of the CC was improved by hardware modifications to change 2 CC/crystal to full ranges of 2.5 and 5 MeV Each crystal now provides 4 CC gains: 2.5, 5, 10 and 30 MeV full range, with 2.5 and 5 MeV ranges showing linear behaviour Software To keep the 10MeV 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 D. Radford ADC units (a.u.) INL units (a.u.) 17

18. 18 A BSOLUTE N ON -L INEARITY M EASUREMENT Delay Amp ORTEC 427A Delay Amp ORTEC 427A Q1A1 #4 Digitizer Module Triangular wave 0.8 V up/down in 0.1 ms 1 ms period Slow ramp -2 -> +2 V, 1.5 s period ch 0 + ch 2 + ch 0 - ch 2 - external trigger from triangular wave generator D. Radford

19. 19 A BSOLUTE N ON -L INEARITY M EASUREMENT Digitized waveform ADC value Time (10 ns samples) dV = constant dt = fixed difference in time 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 dADC/dt for the fast wave at all starting values of the ADC – because dV is constant, this is a measure of the ADC non-linearity. D. Radford

20. 20 R ELATIVE I NTEGRAL N ON -L INEARITY M EASUREMENTS Triangular wave Reference chs Channels to be measured Board 1Board 2 Relative non-linearity measurement are much simpler, simply use a triangular wave into the reference channel + unknown channel to be characterized. 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. D. Radford

21. 21 N ON -L INEARITY S OFTWARE C ORRECTION 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 10MeV 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

22. 22 O NLINE N ON -L INEARITY C ORRECTION Non-linearity correction has shown good results in calibrations, and no indication of problems during in-beam runs has been observed.

23. Thank you! 23

24. 24

25. 25 GRETINA S TAND -A LONE GRETINA IOC … x 29 Timestamped @ 50 MHz Raw data (mode 3) TS ordered, raw data including waveforms Decomposed data (mode 2) TS ordered, decomposed to x,y,z,e GRETINA IOC GRETINA Global Event Builder (GEB) TS orders TS orders, builds 40 channel crystal events, runs decomposition on GRETINA cluster

26. 26 GRETINA + S800 Raw data (mode 3) TS ordered, raw data including waveforms GRETINA ONLY Decomposed data (mode 2) TS ordered, decomposed to x,y,z,e GRETINA + S800 TS orders TS orders, builds 40 channel crystal events, runs decomposition on GRETINA cluster The interaction point between the S800 DAQ and GRETINA is at the GEB – S800 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) S800 CAMAC + VME Readout GRETINA IOCs Timestamped @ 12.5 MHz, using GRETINA clock downscaled by 4

27. 27 ‘S TANDARD R UNNING ’: O UTPUT F ILES In the currently adopted ‘standard’ running mode at NSCL, two output files are generated: 1.“GlobalRaw.dat”: contains time-ordered GRETINA raw channel events only, including a 16-word global header for each unique timestamp Raw (Mode 3) data consists of a header, followed by trace information: struct Geb { int32_t type; int32_t length; /* length of payload in bytes following the header */ int64_t timestamp; }

28. 28 ‘S TANDARD R UNNING ’: O UTPUT F ILES 2.Global.dat”: contains time-ordered GRETINA Decomposed crystal events, GRETINA Bank29 raw channel events, and S800 events, all including the 16-word global headers struct crys_intpts { int type; /* defined as abcd5678 */ 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 long int timestamp; long long trig_time; /* not yet impl */ float t0; 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]; };

29. 29 O NLINE DAQ M ONITORING - GRETINA 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.

30. 30 O NLINE D ATA I NTEGRITY M ONITORING Online data monitoring at NSCL is done via the established NSCL SpecTcl program, which has been modified to sort the combined S800 + GRETINA (Mode 2) data. Thanks to Dirk Weisshaar for writing the SpecTcl code, and for the screenshots.

31. 31 D ATA A NALYSIS Online: Online data analysis at NSCL is essentially restricted to SpecTcl. 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.SpecTcl – the same code used for online analysis can be used offline. There are possibilities using SpecTcl to create intermediate output files, with S800 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 RadWare spectra. These are an excellent starting point for a user who prefers to stay away from SpecTcl/ROOT. Paul Fallon / David Radford 3.ROOT – at present, two independent ROOT analysis codes exist, which analyze both S800 + GRETINA (Mode2/Mode3). 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 wimme1k@cmich.edu) http://www.nscl.msu.edu/~wimmer/software.php

32. 32 D ATA A NALYSIS – O FFLINE WITH ROOT ROOT analysis options both include S800 + GRETINA, and include much of the necessary code for S800 corrections, etc. Data can be sorted into any combination of histograms and/or ROOT tree structures, allowing gating without rescanning of data.

33. 33 D ATA A NALYSIS – T RACKING 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 Mode1, or tracked format. EE At present, Torben’s code can handle BGS data, and enhancements for S800 analysis (with S800physics) are underway. http://www.phy.anl.gov/gretina