VdM analysis framework

1. VdManalysis framework LUMI DPG meeting Jan 28 2014 Dan Marlow, Olga Driga (Princeton) Monika Grothe (Wisconsin) VdM analysis Framework

2. Draft design document Version of Jan 27 is attached to agenda To check out: svnco svn+ssh://username@svn.cern.ch/reps/driga/VdM_doc VdM analysis Framework

3. Design draft document: Content VdM analysis Framework

4. Design Goals Simple and easy to use, such that new users can quickly start doing VdM analysis of their own Encapsulate knowledge gained in previous scan campaigns Modular, such that it is easy to use input from different luminometers and such that different analysis schemes are possible Shield user from having to hand-collect information and corrections necessary for the analysis Allow a particular analysis to be captured and archived, including all input data and all analysis algorithms Facilitate comparison of results of different analyses It should be possible to carry out full analysis offline, for example on a laptop Centrally maintained, using standard version management methods VdM analysis Framework

5. Language and file format Main language will be python/pyroot Data will be stored as python pickle files Other formats (csv, plain text, ROOT) will be used as appropiate VdM analysis Framework

6. Structure: Analysis run in four stages • Stage 1: Data preparation • reads information from various sources and convert to standardized pickle files • Stage 2: Graph production • uses output of stage 1 to produce TGraphError objects • applies corrections to data as necessary • Stage 3: Fitting • also applies corrections to output data of fit, as needed • results stored as ROOT and as pickle files • Stage 4: Comparison • of two or more analyses VdM analysis Framework

7. File structure of analysis and archival VdM analysis Framework

8. Remark on applying corrections • In the interest of maintaining a simple structure, divide corrections in two classes: • Pre-fit corrections (may change fit quality) • Beam-beam correction • Requires a round of intermediate fitting since CapSigma values are needed as inputs • Since effect on CapSigma of length scale, ghosts, satellites etc are generally small, this intermediate fit can be done on otherwise uncorrected data • Post-fit corrections (don’t affect fit quality) • bunch current product • length scale • ghosts • satellites • dynamic beta • emittance VdM analysis Framework

9. Input data files (stage 1 output) • Scan file • Content: basic info about scan (machine parameters, fill and run numbers, scan point data table) • Source: It should be possible to get this info via DB queries from within python code • Info used to come from DIP and via note taking during scan • If currently not possible, would be highly useful to request creation of sucha DB entry • Name: scan_ffff_ppp_nnn. pkl • ffff: fill number • ppp: alias of person creating file, e.g. BRIL for centrally produced files • nnn: version, e.g. 001 • Produced by GenerateScanFile.py • Luminometer data file • Content: python dictionary with lumi per scan point, with BCID as key • Source: From the luminometers • Name: Lumi_llll_ffff_ppp_nnn.pkl • llll: name of luminometer • ffff: fill number • ppp: alias of person creating file, e.g. BRIL for centrally produced files • nnn: version • Production is responsibility of luminometer group in question VdM analysis Framework

10. Input data files (stage 1 output) (II) • Beam current file: • Content: beam current values (DCCT, FBCT) for each scan point • Source: It should be possible to get this info via DB queries from within python code • Info used to come from DIP • Name: BeamCurrent_ffff_ppp_nnn.pkl • ffff: fill number • ppp: alias of person creating file, e.g. BRIL for centrally produced files • nnn: version, e.g. 001 • Produced by GenerateBeamCurrentFile.py • Length scale file: • Content: length scale correction factors • Source: Separate CMSSW based analysis of dedicated length scale data • Name: LengthScale_ffff_ppp_nnn.pkl • Satellite and ghosts: • Content: Current corrections for satellite and ghost contribution • Source: LHCb and/or LDM group • Name: Satellite_ffff_ppp_nnn.pkl Ghost_ffff_ppp_nnn.pkl • Produced by GenerateSatelliteFile.py GenerateGhostFile.py VdM analysis Framework

11. Input data files (stage 1 output) (III) • BeamBeam file: • Content: beam-beam deflection correction to x,y coordinates • Source: Script provided by Kozanecki/machine group • Name: BeamBeam_ffff_ppp_nnn.pkl • ffff: fill number • ppp: alias of person creating file, e.g. BRIL for centrally produced files • nnn: version, e.g. 001 • Produced by GenerateBeamBeamFile.py • Remark: Needs CapSigmas as input, hence requires intermediate fitting stage on uncorrected data VdM analysis Framework

12. Output files • Results file: • Content: see next slide • Name: Results_ffff_ppp_nnn.pkl • ffff: fill number • ppp: alias of person creating file, e.g. BRIL for centrally produced files • nnn: version, e.g. 001 • Plots file: • Content: For each BCID, data with fit result overlaid • Name: Plots_ffff_ppp_nnn.root (TGraphErrors with associated TF1) Plots_ffff_ppp_nnn.pdf (pdf format for easy visualization) • Minuit log file: • Content: Minuit output in simple text format • Name: Log_ffff_ppp_nnn.pkl VdM analysis Framework

13. Output: Results file Discussion needed VdM analysis Framework

14. Driver file and analysis script Discussion needed ! Simple model: creates python dictionary of file names for corrections etc that is passed to VdM analysis script Framework provides template analysis script that can be customized by user VdM analysis Framework