Software, tools and strategies From RAW data to Events: “raw2dst” & “dst2root” C. Guerrero (CERN )

1. Software, tools and strategies From RAW data to Events: “raw2dst” & “dst2root” C. Guerrero (CERN)

2. From RAW data to Events: “raw2dst” & “dst2root” • The data flow at n_TOF: from RAW data to Cross Sections • Production of Data Summary Tapes (DSTs) for each detector: “raw2dst” • Production of ROOT files from DST: “dst2root” • Structure of the ROOT files: TTREE and TBRUNCH • Summary and description of the variables stored in the TTREEs • raw2dst : An iterative process • Reading, projecting and drawing data from ROOT files

3. The data flow at n_TOF: from RAW data to Cross Sections BEHIND THE SCENES Signals from the detectors are digitized and saved in local disk servers. A “zero-suppression” algorithm eliminates “movie” regions below the selected threshold. The resulting RAW data are stored into CASTOR (/castor/cern.ch/ntof/2011/iron57). RAW2DST. The RAW data are transformed into Data Summary Tapes (DST) by dedicated signal analysis routines tuned for each detector type. The DSTs (/castor/cern.ch/ntof/2011/iron57/dst) contain the list of detected signals and their characteristics: RunNumber, EventNumber, tflash, DetectorName, DetectorNumber, SignalTOF, SignalAMP, SignalAREA DST2ROOT. The DSTs (binaries) are transformed into readable ROOT files ACTIONS BY THE ANALYST Projection of the ROOT files into the histograms: usually En/TOF under some conditions (F. Gunsing) Calculation of the reaction yield: weight/efficiency correction + background subtraction. (C. Massimi) Determination of the Cross Section from the point-wise or average reaction yield with SAMMY/REFIT.

4. RAW2DST: Signal Analysis Routines (PKUP) • Particularities: • only one signal per pulse is expected. • A simple algorithm searches for the signal and integrates it over a total of 300 ns(190ns before 2010) FWHM~15 ns Integration over 300 ns

5. RAW2DST: Signal Analysis Routines (SILI) • Particularities: • the flash does not produce saturation. • pile-up is not expected • saturation is not expected • A simple algorithm searches for the signal and integrates it over a total of XX ns. Maximum amplitude FWHM~300 ns

6. RAW2DST: Signal Analysis Routines (MGAS-2010) • Particularities: • the noise is high in the case of the 10B • the signals had total width of ~1200 ns in 2010 and ~300 ns in 2011 (new preamp from Bari) • saturation of some fission signals is expected • A simple algorithm searches for the signal and integrates it over a total of 1500 ns. MGAS (235U) MGAS (10B) FWHM~500 ns FWHM~800 ns Integration over 1500 ns Integration over 1500 ns

7. RAW2DST: Signal Analysis Routines (MGAS-2011) • Particularities: • the noise is high in the case of the 10B • the signals had total width of ~1200 ns in 2010 and ~300 ns in 2011 (new preamp from Bari) • saturation of some fission signals is expected • A simple algorithm searches for the signal and integrates it over a total of XX ns. MGAS (235U) MGAS (10B) FWHM~150 ns FWHM~150 ns Integration over 300 ns Integration over 300 ns

8. RAW2DST: Signal Analysis Routines (C6D6) • Particularities: • signal shape constant • small rebound ~700 ns after the signals • some saturated pulses expected • The average pulse shape is fitted to ach signal, providing better accuracy and pile-up analysis capabilities (care has to be taken to have the correct avg. pulse shapes and make sure they don’t change).

9. RAW2DST: Signal Analysis Routines (TAC) • Particularities: • fast (0.7 ns) and slow (630 ns) components. [the slow comp. carries ~83% of the total charge] • signal VERY noisy • pile-up between slow components expected • saturation of the fast components expected in most signals • The fast and slow components are fitted to a Maxwellian and exponential shapes.

10. RAW2DST: Signal Analysis Routines (caution!!) Caution: The analysis routines are home-made The pulse shapes (time and shape) may change from run to run due to modification of electronics, settings, etc. The production of DST is in fact an iterative process in which the analyst shall report any strange behavior in the data being analyzed.

11. DST2ROOT. Structure of the ROOT files (TTree and TBranch) The data within the ROOT files are structured in TTREEs, one corresponding to each detector type. Each TTREE is named as "nt_XXXX", where the "XXXX" are the four characters that, also in the DAQ, identify each detector type: PKUP: Wall Current Monitor placed in the proton line (1 detector) SILI: Silicon Monitor (4 detectors) MGAS: Monitoring MGAS (2 detectors -> U235=#1 and B10=#2) K6D6: liquid scintillators for capture measurements (2 detectors) BAF2: Total Absorption Calorimeter for capture measurements (40 detectors) PPAC and PPAN: cathodes and anodes of PPAC for fission measurements FTMG: Fission tagging MicroMegas (3 detectors in 2010) HEMG: High Energy MicroMegas detector for fission (10 detectors to be used in 2011) Each TTree contains a number of ‘”Branches”, each corresponding to one variable root [0] TFile f("/afs/cern.ch/user/c/cguerrer/w0/rootfiles_2011/Commissioning/run_11663.root"); root [1] f.ls() TFile/afs/cern.ch/user/c/cguerrer/w0/rootfiles_2011/Commissioning/run_11663.root KEY: TTree nt_mgas;1 MGAS KEY: TTree nt_sili;1 SILI KEY: TTree nt_pkup;1 PKUP KEY: TTree nt_k6d6;1 K6D6

12. DST2ROOT. Structure of the ROOT files (TTree and TBranch) The data within the ROOT files are structured in TTREEs, one corresponding to each detector type. Each TTREE is named as "nt_XXXX", where the "XXXX" are the four characters that, also in the DAQ, identify each detector type: PKUP: Wall Current Monitor placed in the proton line (1 detector) SILI: Silicon Monitor (4 detectors) MGAS:Monitoring MGAS (2 detectors -> U235=#1 and B10=#2) K6D6: liquid scintillators for capture measurements (2 detectors) BAF2: Total Absorption Calorimeter for capture measurements (40 detectors) PPACand PPAN: cathodes and anodes of PPAC for fission measurements FTMG: Fission tagging MicroMegas (3 detectors in 2010) HEMG: High Energy MicroMegas detector for fission (10 detectors to be used in 2011) Each TTree contains a number of ‘”Branches”, each corresponding to one variable root [2] nt_sili->Print(); Tree :nt_sili : SILI Br 0 :RunNumber : RunNumber/I Br 1 :EventNumber : EventNumber/I Br 2 :PSpulse : PSpulse/I Br 3 :PulseIntensity : PulseIntensity/F Br 4 :SILIdetn : SILIdetn/I Br 5 :SILItof : SILItof/F Br 6 :SILIneutene : SILIneutene/F Br 7 :SILIamp : SILIamp/F Br 8 :SILItflash : SILItflash/F

13. DST2ROOT. Variables stored in the TTREEs (1) • The data contained in the TTrees are direct translation from the variables recorded in the DST file, except for the "tflash" and the neutron energy that are derived quantities. • Some variables are exactly the same in all TTrees: • RunNumber: it is the Run Number that can be also seen in "ntofdaq.cern.ch“ • - EventNumber: each event corresponds to a single neutron pulse. Thus the variables "tflash" is similar in all entries within the same event. • - PSpulse: refers to the type of pulse which can be "1" (dedicated) or "2"(parasitic) • - PulseIntensity: is the proton beam intensity according to the transformer TRF468. For relative normalization purposes it is recommended to use the information from the PKUP or event better that of SILI or MGAS.

14. DST2ROOT. Variables stored in the TTREEs (2) • Other variables have their name preceded by 4 characters that depend on the detector. These variables are: • - XXXXtflash [ns]: except in the case of the PKUP, the time of the tflash is not easy to identify or all detector types and the accuracy in its determination may vary with the intensity of the incident neutron pulse. Therefore the variable stored in the TTrees correspond to that of the PKUP corrected by the time distance observed in the Event Display between the flash in the PKUP and the corresponding detector. • XXXXtof[ns]:It corresponds to the Time-of-Flight to the time of the signal given by analysis routines. This is RAW time in the sense that it does not considers the calibration between digitizers neither the offset with the respect to the time of the incident proton beam. • This variable is not in the DST but is derived afterwards. The calculation involves the TOF of XXXneutene [eV]:each signal (given in the DST), the "tflash" (calculated form the PKYPtflash) and the "TOF distance", measured in the EAR-1 r calibrated from low energy resonances. • - XXXamp [flash-ADC channels]:amplitude of the signal in flash-ADC channels (0-256) [even higher values than 256 if the analysis routine is suited for reconstructing saturated pulses] • - XXXarea [flash-ADC channels]:area of the signals integrated, usually, well beyond the start and end of the signal. • - XXXdetn [integer]:number identifying each of the detectors of a given type.

15. Reading, projecting and drawing data from ROOT files (1) read_sequential() { TFilef("/afs/cern.ch/user/c/cguerrer/w0/rootfiles_2011/iron57/iron57_11732.root");// Open ROOT file // Create variables to store the data read from each entry of the TTREE Int_tSILIentries, SRunN, SEventN, SPSpulse, Sdetn; Float_tSPSprot, Stof, Sneutene, Samp, Sarea, Stflash; // Associate the value of each "TBranch" of the "TTREE" with the corresponding local variable nt_sili->SetBranchAddress("RunNumber",&SRunN); nt_sili->SetBranchAddress("EventNumber",&SEventN); nt_sili->SetBranchAddress("PSpulse",&SPSpulse); nt_sili->SetBranchAddress("PulseIntensity",&SPSprot); nt_sili->SetBranchAddress("SILIdetn",&Sdetn); nt_sili->SetBranchAddress("SILItof",&Stof); nt_sili->SetBranchAddress("SILIneutene",&Sneutene); nt_sili->SetBranchAddress("SILIamp",&Samp); nt_sili->SetBranchAddress("SILItflash",&Stflash); // Loop over the total number of entries in the TTREE SILIentries = nt_sili->GetEntries(); // Read Number of Entries Int_tprevEvt=-1; for(Long64_t i=0; i < SILIentries; i++) { nt_sili->GetEntry(i); if(SEventN>prevEvt) { cout<<"Run:"<<SRunN<<", Ev:"<<SEventN<<" of type "<< SPSpulse<<" with "<<SPSprot<<" protons. (tflash="<<Stflash<<" ns)"<<endl; prevEvt=SEventN; cout <<"(Press key to continue)"<<endl; getchar(); } cout << "Signal in SILI #"<<Sdetn<<" of amplitude "<< Samp<<" detected at TOF="<<Stof<<" ns ("<<Sneutene<<" eV)"<<endl; } return; }

16. Reading, projecting and drawing data from ROOT files (2) project_plot() { // Create Canvas with 2 pads c1 = new TCanvas("c1","",1000,500); c1->Divide(2,1); // Open ROOT file TFile f("/afs/cern.ch/user/c/cguerrer/w0/rootfiles_2011/iron57/iron57_11732.root"); // One can project and plot one (1D) or two (2D) variables of the TTree under any condition in the other variables // 1D TH1F *h1d = new TH1F("h1d","Amplitude in SILI #1; Amplitude (flash-ADC channels); Counts",256, 0, 256); nt_sili->Project("h1d","SILIamp","SILIdetn==1 && SILIneutene<1e4"); // 1D c1->cd(1); gPad->SetLogy(); gPad->SetGrid(); h1d->DrawCopy("E0histo"); // 2D TH2F *h2d = new TH2F("h2d","Amplitude vs. Log(E_{n}) in the SILI #1; Log(E_{n}[eV]); Amplitude(flash-ADC channels)",180,-2,4,250,0,250); nt_sili->Project("h2d","SILIamp:TMath::Log10(SILIneutene)","SILIdetn==1"); // 2D c1->cd(2); gPad->SetLogz(); gPad->SetGrid(); h2d->DrawCopy("zcol"); return; }

17. Summary and conclusions The generation of DST and their conversion to readable ROOT files are the first steps of the data analysis. The whole process has been summarized and some documentation is available at : https://twiki.cern.ch/twiki/bin/view/NTOF/NTOFDST2ROOT (nTOF Wiki → n_TOF for Users → Data Analysis → Data Processing dst2root) The process is blind to the “user”, BUT feedback is really necessary in order to converge to accurate and trustable DSTs. This is because ALL Signal Analysis Routines need to be continuously tested and sometimes improved or fine tuned. The ROOT files are batch generated from the DST and are stored in: /afs/cern.ch/exp/ntof/ROOTDATA/