Calorimeter Ground Software Review

1

• Calorimeter Ground Software Review
• J. Eric Grove
• Naval Research Lab
• Arache Djannati-Atai
• Collège de France

2
Outline

• Introduction
• Manpower/Organization
• Project-wide Schedule
• Scope of Task
• Simulation
• Status
• Plans, Needs
• Data Analysis (toward Reqmts doc for each step)
• Calibration
• Recon
• Documentation
• Code Management
• Manpower Schedule

3
Introduction

• GLAST is next-generation HE gamma-ray telescope
• Energy range 20 MeV 300 GeV
• Modest spectroscopy DE 10 (0.1 100 GeV)
• Recall GLAST science for Calorimeter
• Spectra from astroph sources are generally quite
  simple.
• Power laws, exponential breaks, smooooooth.
• Calorimeter design
• Hodoscopic array of CsI(Tl) logs
• 1536 logs
• 3072 or 12288 channels of spectroscopy, depending
  on data mode
• Segmentation of CsI allows
• Shower energy profiling (These are primary
  functions of CAL)
• Shower imaging
• Background rejection
• Collaboration among US, France, and Sweden

4
Calorimeter Concept
Hodoscopic Array of CsI Crystals 8 layers of 10
crystals at beam test PIN photodiodes on each end
BTEM Prototype calorimeter
Mechanical Structure Minimize passive material,
maximize active volume Mounts inside grid
structure. EMI shielding against Tracker readout
Readout electronics on each side Custom
ASICs COTS ADCs readout 2 x 105 dynamic range lt20
msec deadtime
5
New Mechanical Concept IN2P3

• New mechanical concept proposed by IN2P3
• CsI logs held in individual C-composite sleeves
  with reflective inner surface.
• Cell end-caps hold crystal against transverse
  motion.
• Logs no longer held with large vertical load and
  stiction.

Implications for Simulations Different amount and
distribution of passive material. Different
active geometry. So far, readout is unchanged.
6
Positioning with Light Asymmetry

• SLAC e- beam, 2 GeV
• DE 130 MeV
• rms 3 mm
• Note at DE 5 GeV, rms 0.3 mm!

7
CAL s/w Organization

• Calorimeter Subsystem Manager
• W.N. Johnson (NRL)
• CAL Software Manager
• J.E. Grove (NRL)
• A. Djannati-Atai (CdF)
• Fr. Instrument Scientist
• CAL software team at NRL
• Current s/w tasks
• Scientists 1.3 FTE
• S/W engineers 0.3 FTE
• Data Analysts 0.4 FTE
• Postdoc (open) 1.0 FTE
• Just starting
• Scientists 0.1 FTE
• S/W engineers 0.3 FTE

• CAL software team in France
• Current s/w tasks
• Scientists 2.3 FTE
• Grad students 1.0 FTE
• Logistical support 0.3 FTE
• Just starting
• Scientists 1.5 FTE
• Institutions
• Collège de France
• Saclay
• CENBG (Bordeaux)
• Given 7 FTE in CAL team, WAG levels of effort
  allocation
• Design Doc (60) 4.3 FTE
• Coding (15) 1.1 FTE
• Testing/Running (25) 1.8 FTE
• Total 7.2 FTE

8
History of CAL s/w Development

• Many people outside the CAL group have
  contributed to the development of CAL ground s/w,
  in simulations and analysis.
• These people have done far more work than anyone
  else on calorimeter software.
• Toby Burnett (UW)
• Sawyer Gillespie (UW)
• Code architecture, management
• Simulation development and code
• Heather Arrighi (GSFC)
• Simulation code
• First recon code
• Still going strong!
• Jay Norris (GSFC)
• Simulation studies

• Jose-Angel Hernando (UCSC)
• Wrote majority of Recon code
• Framework and first-pass algorithms
• Dan Flath (SLAC)
• ROOT architecture and code
• Dan Suson (TAMUK)
• Simulation tools for CAL readout
• CAL implementation
• And of course
• Bill Atwood (SLAC)
• GLAST concept and motivation
• Simulation development and code
• First recon code
• Analysis

9
Management/Coordination

• Collaboration is spread world-wide
• How do we all communicate?
• Weekly GLAST/LAT software meetings with vrvs
• Weekly Calorimeter Ground Software meetings with
  vrvs
• Open discussion of work in progress
• Free form
• Minutes are available at http//gamma.nrl.navy.mil
  /glast/CalSW/
• Weekly NRL Team meeting with Face-to-Face
  Communications Protocol.

10
Schedule

• Calorimeter software development is driven at
  highest level by a number of Project-wide
  Milestones.
• System Requirements Review Oct 2000
• Beam Test 99 paper Nov 2000 (?)
• Calorimeter PDR Dec 2000
• Balloon Flight May 2001
• Instrument PDR Aug 2001
• Instrument CDR July 2002
• Launch
• We need to develop CAL s/w plan consistent with
  those milestones.
• Requirements, Implementation, Testing

11
Scope of Task

• Simulation of all GLAST subsystems
• Flight model
• Beam Test model
• Balloon Flight model
• Production Data Analysis (PDA)
• PDA will eventually occur at Instrument
  Operations Center (IOC)
• PDA is a process that generates standard data
  products.
• CAL State Tracking
• CAL Calibration
• Electronic calibration
• GCR calibration
• CAL Recon (evolving into Global Recon), an
  iterative procedure
• Energy reconstruction
• Trajectory reconstruction
• Background Rejection
• Instrument Response Fcn/Matrix
• Items in color (and their subtopics) are
  discussed here. Green means it exists. Red
  means new item.

12
Scope of Task

• Also Ground s/w, but beyond scope of this review
• CAL ground support equipment (CalGSE)
• Command generation control (in use, complete)
• Command state verification (prototype for
  balloon flight?)
• Health Safety Monitoring (prototype for
  balloon flight?)
• Data logging (in use, complete)
• CAL simulator
• CAL bench-checkout
• Low-level analysis, recon (in use, extensive
  suite)

13
Simulations

• Calorimeter simulation studies needed
• Optimize CAL-only triggers.
• Simulation needs new flexibility to define
  triggers.
• Need this to proceed with CAL design.
• What is rate of multi-MIPs in ACD for everything
  but primary GCRs?
• Sources of multi-MIP backgrounds?
• Significant or negligible increase in data
  volume?
• Energy corrections, measured DE to incident
  energy.
• TKR passive material.
• CAL passive material (6 mm Al grid walls, Fr.
  Mechanical cell closeout, )
• Need to model system performance with failures
  (PIN, xtal, DAQ pipe,...).
• Implement Performance State.

14
Simulation Needs

• Separate the physics from the instrumental
  effects. I propose three levels of output.
• MC Truth
• Full energy accounting, all volumes (active,
  passive, beam dump).
• Scores where and how much energy deposited.
• Q how coarse can the scoring be and still allow
  post-processing?
• Ideal Instrument
• Voxellates this info into flight-like readout,
  but perfect detectors.
• Incorporates light tapering, 2 diodes per end, 4
  ranges per end,
• This is the primary output of the sim, on which
  multiple Real Instrument configs are tried.
• Q should this be done interaction-by-interaction
  , or by post-processor from MC Truth?
• Realistic Instrument
• Non-linearities, dead channels, gain differences,
  electronic noise, photoelectron noise,
• Output looks like a GLAST data stream.
• All effects are added by post-processor with
  parameters adjustable at run time. Identical MC
  can be dirtied several different ways.

15

• Production Data Analysis
• PDA will eventually occur at Instrument
  Operations Center (IOC)
• It must be usable by someone other than the s/w
  team.
• PDA is a process that generates standard data
  products.
• CAL State Tracking
• CAL Calibration
• Electronic calibration
• GCR calibration
• CAL Recon (evolving into Global Recon), an
  iterative procedure
• Energy reconstruction
• Trajectory reconstruction
• Background Rejection
• Instrument Response Fcn/Matrix

16
State Tracking

• State Tracking (new)
• Level 1 PDA must track the state of the
  instrument
• Command State
• The verified configuration of the h/w.
• Analysis needs to know data modes, etc.
• Created by first-pass L1 processing, MOPS tasks.
• Performance State
• Documents performance not described by Cmd State
  dead logs, bad gain ranges, etc.
• Created by first-pass L1 processing.
• Output feeds into Cal Recon, allows fault
  tolerance in Recon.
• Calibration State
• Created by Calibration in L1 processing.
• Output feeds into Cal Recon, Cal Calib Parameter
  DB.
• Develop in concert with TKR, ACD, DAQ.
  System-wide service.
• Simulation could refer to various States for Real
  Instrument generation.

17
State Tracking

• Inputs
• Level 0 data stream
• Cmd state DB
• Output class
• StateServer (Cmd State, Perf State, Calib State)
• Work Plan and Schedule
• Status All new. Only Calib Parameter DB is
  under development.
• Priority Modest. No need for BT99, helpful for
  balloon flight.
• Cmd State is lowest priority. Balloon cmd will
  be trivial.
• Perf State would be useful in balloon flight
  analysis.
• Calib State must integrate with Calib Parameter
  DB development.
• Schedule Intermediate term. Prototype
  after/with balloon flight.

18
Performance State

• Performance State
• Allows Recon to interpret CAL data stream and
  give optimal event reconstruction.
• Documents data modes, anomalous conditions.
• Functional requirements
• Contents (corresponds to Flight s/w doc)
• Hot log list
• Failed gain range list
• Tower State
• Failed towers
• Failed CAL sides/signal chains
• Pointer to entry in CAL Calibration Parameter
  Database
• Work Plan and Schedule
• Status New work.
• Priority Modest. Potentially helpful for
  balloon flight and Real Instrument.
• Schedule Intermediate term. Prototype
  after/with balloon flight.

19
Calorimeter Calibration

• In-Flight Calibration
• Supplements and corrects detailed pre-launch
  calibration.
• What needs to be calibrated?
• Energy measurement
• Need relative calibration among crystals and
  overall absolute calibration.
• Goal Relative calib lt1 at all energies.
• Goal Absolute calib 3 at all energies.
• Position measurement
• Need light asymmetry calibration in each crystal.
• Requirement from bkg-rejection 3 cm knowledge
  (10 of crystal length).
• Requirement Light asymmetry slope knowledge to
  10.
• Goal Improve pointing for conversions in
  SuperGLAST.
• Need 3 mm knowledge.
• Goal Light asymmetry slope knowledge to 1.

20
Calorimeter Calibration

• Functional requirements (top level)
• Electronic calibration eCalib shall generate
  pedestal and integral linearity model for each
  gain range for each PIN diode.
• Required accuracy is TBD goal is 3.
• Data source is Charge-Injection Calibration Mode.
• Absolute light yield GCRCalib shall calculate
  the absolute light yield at the center of each
  log for each PIN diode.
• Required accuracy is TBD goal is 3.
• Data source is GCR Calibration Mode.
• Light asymmetry model GCRCalib shall produce
  maps of light asymmetry (i.e. light collection
  efficiency as a fcn of longitudinal position) of
  each log end and the sum of ends for each log.
• Required accuracy is 10 goal is 1.
• Data source is GCR Calibration Mode.

21
GCR Calibration

• Cosmic Ray Calibration (new)
• High flux of GCRs gives good calibration over
  full dynamic range (see Appendix).
• Derive calibration with statistical precision of
  better than few each day over full dynamic
  range.
• Flight s/w flags and telemeters GCR data in
  Calibration Mode (4-Range Mode).
• Might be pre-scaled to reduce data volume.
• This would give longer times between calibration.
• Functional Requirements
• GCRCalib shall process Calibration Mode
  telemetry.
• GCRCalib shall query Perf State to modify
  algorithms, fault tolerance.
• GCRCalib shall identify non-interacting GCRs with
  clean TKR trajectories through logs.
• GCRCalib shall accumulate energy loss and light
  asymmetry maps in GCR DB.
• See algorithms.

He 140 Hz CNO 10 Hz ? 1100 per xtal
per day Si 0.4 Hz Fe 0.8 Hz ?
70 per xtal per day
22
GCR Calibration Process

• Algorithms
• Physics inputs
• dE/dx for heavy ions. Code expressions from the
  literature.
• dL/dE for heavy ions. Measure it, then code it.
  Analytic expr. exist.
• Elements of calibration process
• Extract multiMIP events.
• Identify likely GCRs, reject obvious junk.
• Fit tracks.
• Accept events with clean track through log, no
  edges or glancing hits.
• Identify charges.
• Identify charge-changing interactions.
• Identify mass-changing interactions.
• Fit dE/dx.
• Accumulate energy losses and light asymmetries.

23
GCR Calibration

• Inputs
• Calibration Mode TLM
• StateServer (Cmd State, Perf State)
• Outputs
• GCR database
• Gain
• Cal Parameter DB
• Work Plan and Schedule
• Status New. Algorithms can be developed with
  GSI 00 data and balloon flight data.
• Priority Moderate. After balloon flight.
• Schedule Intermediate term.

24
Chg-Injection Calibration Process

• eCalib (IDL prototype)
• Functional Requirements
• eCalib shall extract pedestal and pedestal width
  entries from Housekeeping telemetry, and insert
  into Cal Parameter Database.
• eCalib shall fit an analytic model converting raw
  ADC bins to charge at the preamp input (fC) from
  Charge-Injection Calibration Mode data.
• eCalib shall query Perf State to determine the
  functional state of CAL, fault tolerance.
• eCalib shall query Cmd State to determine
  Charge-Injection Calibration program steps.
• Algorithm
• Fully defined in existing IDL code.
• Inputs
• HK telemetry
• StateServer (Cmd State, Perf State)
• Outputs
• Pedestals, ADC to fC model in Cal Parameter DB
• Work Plan and Schedule
• Status IDL code for basic process is complete.
• Code for CAL Parameter DB, Perf State and failure
  modes does not exist.
• Priority Low. Current method is adequate until
  long after balloon flight.
• Schedule Long term.

25
Calibration Parameter Database

• The various calibration processes produce a
  number of parameters describing the response of
  the CsI logs.
• All are time-dependent (TBR).
• Time scale is likely to be weeks to months
  (TBR).
• Calibration Parameter Database is a service of
  Software Central.
• Pedestals
• Accumulated on board
• Telemetered pedestal, pedestal width,
  diagnostic histogram
• Optional diagnostic mode telemeters full CAL data
  set, i.e. not zero-suppressed.
• 2 bytes x 2 parameters x 4 ranges x 2 ends x 1536
  logs 48 kB
• Differential linearity correction
• Make the CDB smooth.
• Worth thinking about some more. Consider 1 byte
  per ADC bin per range.
• 1 byte x 4096 channels x 4 ranges x 2 ends x 1536
  logs 50 MB

26
Calibration Parameter Database

• Integral linearity correction (ADC to fC)
• Electronic calibration
• Internal charge-injection circuit used during
  in-flight diagnostic mode
• 4 bytes x 10 parameters x 4 ranges x 2 ends x
  1536 logs 480 kB
• GCR calibration
• Might uncover additional non-linearities. Might
  not thus these might not be used.
• 4 bytes x 5 parameters x 4 ranges x 2 ends x 1536
  logs 240 kB
• Gain (optical conversion efficiency fC to
  MeVcenter of log)
• Accounts for light collection electrons at
  preamp per MeV deposited
• Calculated from GCR Calibration data. Updates
  ground calibration.
• 4 bytes x 4 ranges x 2 ends x 1536 logs 48 kB
• Light attenuation model (MeVcenter to
  MeVposition)
• Accounts for variation of light collection along
  each log.
• Calculated from GCR Calibration data. Updates
  ground calibration.
• Small and large PINs have same light attenuation,
  so each log has 3 models
• Individual ends
• 4 bytes x 5 parameters x 2 ends x 1536 logs 60
  kB

27
Energy Reconstruction

• Energy reconstruction process
• The primary scientific function of the
  calorimeter is to measure the energy of incident
  photons.
• Much of the incident energy escapes the
  calorimeter.
• Lost in passive material in TKR and CAL.
• Escapes out the back or out the side.
• By design, the segmentation of the CAL provides
  the opportunity to improve our knowledge of the
  incident energy of the photon/particle.
• Functional requirements (top level)
• Energy per log Recon shall calculate the energy
  deposited within individual CsI logs.
• Incident energy Recon shall estimate the
  incident photon/particle energy.

28
Energy Reconstruction

• Energy per log
• The fundamental energy measurement is the energy
  deposited in each CsI log.
• Multiple PIN diodes and amplifier chains are
  available on each log.
• All must be calibrated. Recon assumes that this
  has been done.
• Functional requirements
• Recon shall consider that each log end reports a
  measurement of the full energy deposited in the
  log.
• Recon shall apply a position-dependent
  light-collection map based on the projected track
  through the log.
• Note in normal operation, this is a weak fcn of
  position if one diode has failed, this is a
  strong fcn.
• CsIDetectorLightAtten method has been the
  source of much confusion.
• Recon shall inspect the current Performance State
  and modify algorithms as appropriate.
• In normal operation, Recon shall average the two
  ends of each log to improve the estimate of the
  full energy deposited.
• If one end has failed, Recon shall report the
  single functioning end.
• If the optimal gain range has failed, Recon shall
  use the range telemetered.

29
Energy Reconstruction

• Recon shall apply calibration parameters, convert
  from data units to MeV.
• Subtract pedestals.
• Non-linearity corrections.
• Accounts for electronic effects
• Output charge at preamp input
• Gain corrections.
• Accounts for optical contact, electrons per MeV
• Output MeV deposited, as measured in each diode
  and gain range.
• In 4-Range Readout mode, Recon shall determine
  the Best Range for the energy measurement.
• Best Range typically is gain range with greatest
  signal not at rail.
• Recall, standard mode has only one range
  telemetered.
• What about Full Readout mode (i.e. non
  zero-suppressed readout)?

30
Energy Reconstruction

• Inputs
• StateServer (Perf State, Calib State)
• Outputs
• posEnergy, negEnergy, energy
• Work Plan and Schedule
• Status
• Code for Best Range is committed.
• Code for Calibration parameters is committed.
• Code for light collection maps and Perf State
  does not exist.
• Priority Moderate. Current performance is
  adequate for BT99 paper and balloon flight.
• Schedule Intermediate term. Review and update
  after balloon flight or sim update.

31
Energy Reconstruction

• Incident Energy
• The primary fcn of the CAL is to estimate the
  incident energy of the photon/particle.
• Incident energy estimate
• To first order, sum of signals in CsI.
• Several correction factors.
• Energy loss in TKR
• Dominant at low energies (100 MeV).
• Longitudinal leakage
• Dominant at high energies (100 GeV).
• Side leakage
• 10-20 of Aeff has significant escape out the
  side.
• Passive material in CAL.
• Most important contributor tower walls.
• Direct deposition in PIN diodes.
• Small correction (A. Djannati-Atai memo in
  progress)
• Maybe this isnt so much a correction as an
  additional measure of incident energy, with
  different response fcn than CsI.
• Iterative procedure

32
Energy Reconstruction

• Functional requirements
• Recon shall estimate the incident energy of
  photons.
• Recon shall correct for energy lost in TKR,
  longitudinal leakage, side leakage, passive
  material in CAL, direct deposition in PINs.
• Recon shall support multiple algorithms for
  incident energy estimation.
• Optimal algorithm might vary with total E in CAL,
  incident angle, failure modes.
• Inputs
• posEnergy, negEnergy, energy
• StateServer
• detGeo, calorimeterGeo geometries
• Outputs
• Energy
• Energy Uncertainty
• Work Plan and Schedule
• Status Code for profiling committed. Other
  algorithms under development.
• Code for TKR E loss, passive material, side
  leakage is primitive.
• Priority High. Essential to BT99 paper.
• Schedule Near term.

33
Trajectory Reconstruction

• Calorimeter-only trajectories
• By design, the GLAST calorimeter is hodoscopic.
• A shower passage through a given CsI log has
  associated with it three coordinates, two
  according to log ID and a third along the log at
  the Center of Light (CL) position.
• The ensemble of position measurements can be used
  to measure the incident trajectory.
• TKR has primary responsibility of shower imaging,
  but
• Conversions deep in TKR can benefit from CAL
  information.
• Low-energy photons benefit from CAL clustering,
  energy per pair.
• Unified TKRCAL trajectory recon for some or all
  event types.
• CAL-only imaging may be useful in some cases.
• Functional requirements (top level)
• Position calculation Recon shall calculate
  positions of interactions within individual CsI
  logs.
• Trajectory reconstruction Recon shall estimate
  the incident photon direction from CAL
  information.
• TKRCAL trajectory reconstruction Recon shall
  support Global Recon, as appropriate.

34
Trajectory Reconstruction

• Position calculation
• A shower passage through a given CsI log has
  associated with it three coordinates, two
  according to log ID and a third along the log at
  the Center of Light (CL) position.
• Functional requirements
• Recon shall determine the two index positions and
  one CL position in each log from the Energy
  measurements.
• Recon shall estimate the uncertainty in the CL
  position.
• Contributions from photon counting statistics,
  electronic noise, error in the light asymmetry
  map,
• Recon shall inspect the current Performance State
  and modify algorithms as appropriate.
• Failed log end no position information.
• Failed gain range could degrade position.
• Flag logs with no useful position information.

35
Trajectory Reconstruction

• Inputs
• posEnergy, negEnergy
• StateServer
• calorimeterGeo, detGeo geometries
• Outputs
• Position
• Position Error
• Work Plan and Schedule
• Status
• Code for simple position calculation is
  committed. Model should be improved.
• Code for position uncertainty exists but is not
  committed.
• Code for Perf State and failure modes does not
  exist.
• Priority Moderate. Current performance is
  adequate for BT99 paper.
• Schedule Intermediate term. Review and update
  after balloon flight or sim update.

36
Trajectory Reconstruction

• Trajectory reconstruction (prototype)
• The incident direction of the primary photon can
  be estimated from the shape of the shower in the
  calorimeter.
• Functional requirements
• Recon shall estimate the incident angle and its
  associated uncertainty.
• Recon shall support multiple algorithms, as
  appropriate.
• Algorithms
• Principal moments.
• Special cases on axis and on cornrows.
• CL position is so precise that simple linear
  least-squares is better.
• Recon shall inspect the current Performance State
  and modify algorithms as appropriate.
• Inputs
• Position, Position Error
• calorimeterGeo Instrument Geometry
• Outputs
• CsICluster Vector, Uncertainty
• Work Plan and Schedule

37
Clustering

• Clustering
• Identifying event clusters and their geometry
  contributes to bkg rejection.
• And contributes to reconstructing the incident
  photon direction.
• Knowing the energy in each daughter of the
  initial pair conversion improves the TKR
  trajectory reconstruction. Create Global Recon.
• This process is all still conceptual.
• Functional requirements
• Recon shall identify event clusters in the
  calorimeter.
• Recon shall associate an event cluster with each
  initial daughter, if possible.
• Above 300 MeV, this is not possible.
• Recon shall report to TKR Recon if cluster
  separation is possible.
• This allows for a second pass at TKR trajectory
  reconstruction.
• Inputs
• posEnergy, negEnergy, energy
• StateServer Perf State
• calorimeterGeo geometries
• Outputs
• CsICluster, moments, topological variables

38
Background Rejection

• Background rejection
• GLAST/LAT requires gt105 1 cosmic-ray rejection!
• Calorimeter is integral part of discrimination.
• On-board trigger
• CAL contributes to bkg rejection in L2T and L3T.
• Downlink rate is 30 Hz (from the AO Proposal)
• Source rate (i.e. the signal) is 15 Hz.
• Ground processing
• Largest contributor to residual bkg
• GCR primaries interacting in s/c material below
  GLAST/LAT.
• Shape of cluster and pattern within CAL cluster.
• Functional requirement (top level)
• Background rejection Recon shall shall support
  background rejection with energy, position,
  clustering, and trajectory information.

39
Background Rejection

• Algorithms
• This process exists so far only in embryonic
  form. Worthy of more study!
• CAL process defn in AO Proposal
• Calorimeter Cluster
• Require the shape of the energy deposition to be
  consistent with EM shower.
• Require the highest-quality track to point to the
  energy centroid in the CAL.
• Number of CAL Clusters
• Energy-dependent maximum number of crystals with
  gt1 of total energy.
• Inputs
• CsICluster, CsIClusterList
• Outputs
• Work Plan and Schedule
• Status S. Ritz (GSFC) responsible for
  bkg-rejection algorithms. B. Phlips (NRL) has
  ideas
• Priority Moderate.
• Schedule Intermediate term. Must be
  coordinated with S. Ritz.

40
Software Documentation

• Doxygen
• GLAST s/w group has adopted doxygen.
• What it does.
• if people are will to do the work.
• Good low-level docs for code developers.
• Well-suited to OOP.
• What it doesnt do.
• Software requirements doc.
• Software design description.
• Users guide to PDA for team members or IOC
  staff.
• Users guide to GAP (GLAST Analysis Package) for
  Guest Investigators.

41
Software Documentation

• Top level
• Eric and Arache will write CAL Ground Software
  Requirements Doc.
• Functional requirements. Due 8 Dec 2000
• Draft Class definitions, relationships. Due
  14 Jan 2001
• Draft Algorithms/Methods. Due 14 Jan 2001
• Draft Test plan scope and reqmts. Due 14
  Jan 2001
• Need to coordinate with TKR, etc.
• Code level
• If you write the code, you write the
  documentation.
• Sacha will document additions to glastsim, tbsim,
  TBRecon Due 10 Nov 2000
• diodes, calib coefs, etc.
• Regis will document energy recon in
  TBRecon Due 10 Nov 2000
• shower profiling, correlations
• Each functional unit.
• Class relationships must be clearly defined (here
  fancy-s/w-of-the-month helps).
• Plain ASCII text is fine! No fancy-s/w-of-the-mon
  th is necessary, but it might help.
• Name

42
Bringing Code On Line

• Code Management
• Need to write a serious Requirements Document
• Code development will flow from design (we
  hope!).
• Assigned to Eric and Arache.
• Need to identify an individual responsible for
  each task area.
• Leader can assemble a team (CAL-only, GLAST-wide,
  whatever).
• Team reports to leader, who ensures consistency
  with design requirements.
• E.g. We now appoint Regis Terrier as team leader
  for high-energy recon.
• Each functional unit needs a Test/Validation
  procedure.
• Written by someone other than code author.
• Need to schedule periodic, occasional internal
  (i.e. CAL-only) code reviews.
• Lead by CAL Subsystem Mgr and Software Managers.
• Informal review.
• Does implementation agree with design?
• Is it better than design? If so, update
  documentation.
• Consistent with GLAST-wide code management,
  configuration management tools.

43
Testing and Validation

• All new CAL functional units must be tested and
  verified before commission.
• A functional unit is code at the process level
  outlined here, e.g. Energy per log, Incident
  Energy, eCalib, GCRCalib.
• How do we verify existing, configured code?

44
Calorimeter Schedule
45
Work Plan, Schedule

• High priority, short term
• Cal S/W Requirements Spec 14 Jan 2001
• Highest priority item
• Assign responsibilities for Functional
  Units/processes 14 Jan 2001
• Document existing sim and recon s/w 10 Nov
  2000
• Incident energy algorithms 3 Nov 2000 (??)
• Pick best so far, implement for BT99 paper
• Complete BT99 analysis ltlt coordinate with
  E.d.C.e.S. gtgt
• Finish the paper
• Build instrument.xml (and more) for French CAL
  concept 3 Nov 2000 (??)
• Lots of similarities, but it is different.
• Moderate priority, intermediate term
• Performance State after balloon flight
• Create, link to sim
• Calibration process (GCRCalib) after balloon
  flight
• Inc. analysis of GSI 00 beam test data
• Energy per log
• Update algorithms, incorporate maps, Perf State,
  Calib State

46
Work Plan, Schedule

• Position calculation
• Update sim and recon models
• CAL trajectory reconstruction
• Clustering algorithms
• Background rejection algorithms
• Low priority, long term
• Calibration process (eCalib)
• Instrument Response Matrix
• Requires extensive Sim running.
• Wait until after Sim is revamped.

47
Manpower

• Calorimeter Subsystem Manager
• W.N. Johnson (NRL)
• CAL Software Manager
• J.E. Grove (NRL) 60
• Current work eCalib, GCRCalib, Position/traj.
  alg.
• CAL software team at NRL
• D. Wood (Elec/Software Eng.) 30
• Current work Position/traj. algorithms
• M.S. Strickman (Astroph) 60
• Current work Simulations, GTOCC
• W.N. Johnson (Astroph) 10
• Current work Reqmts, GTOCC
• B. Phlips (Astroph) 10
• Current work Bkg rejection
• D.P Sandora (Tech, Analyst) 20
• Current work Light yield calib analysis
• D. Messina (Analyst) 20
• Current work Electronic calib analysis

• CAL software team in France
• A. Djannati-Atai (CdF, Physicist) 50
• Fr. Instrument Scientist, Fr. S/W Manager
• Current work Recon Energy alg. CAL-TKR
  feedback GTOCC
• A. Chekhtman (CdF, Physicist) 100
• Current work TBRecon
• R. Terrier (CdF, grad student) 50
• Current work Recon Energy alg. CAL-TKR
  feedback Science analysis (unbinned ML)
• P. Espigat (CdF, Physicist) 30
• Current work Computing logistical support
• T. Hansl-Kozanecka (Saclay, Phys) 50
• Current work Code mgt, Gaudi
• T. Reposeur (CENBG, Physicist) 50
• Future work BT analysis
• S. Incerti (CENBG, Physicist) 50
• Future work GCR Calib
• B. Lotte (CENBG, Physicist) 100
• Future work GCR Calib?

48
Appendix 1Calorimeter Calibration

• How often do calibration parameters need to be
  updated? Timescales of Weeks.
• CsI light yield varies with radiation dose.
• Test at NRLs 60Co Irradiation Facility to 20
  kRad (20 years or more on orbit) showed 25
  degradation in light yield.
• So 1 per year, very long timescale.
• CsI light yield varies with temperature, 1/2
  per deg C.
• Large thermal mass ? no DT effect on orbital time
  scales.
• Long-term DT possible from thermal surface
  degradation or seasonal exposure.
• Active thermal control minimizes this effect.
• PIN diode bonds may degrade with time.
• CLEO degradation was slow. Hamamatsu has fixed
  problem.
• Failure on launch is more likely. Calibrate it
  out once.
• FEE gain and linearity may vary with radiation
  dose.
• DMILL process is tolerant to relatively small
  dose on orbit.
• Any change will be on long timescale.
• FEE gain and linearity may vary with temperature.
• Again, thermal mass of calorimeter means
  timescale is long.

49
Appendix 1Calibration with Cosmic Rays

• High flux of GCRs gives good calibration of full
  dynamic range.
• Concept
• ACD flags events gt few MIPs.
• ACD flags 1 in 1000 single-MIPs.
• Accept only events with good TKR.
• Accept only events with no charge-changing
  interactions in CAL.
• Correct DE for pathlength in CsI bar.
• Accumulate dE/dx in each bar.
• Derive calibration with statistical precision of
  better than few each day over full dynamic
  range.

He 140 Hz CNO 10 Hz ? 1100 per xtal
per day Si 0.4 Hz Fe 0.8 Hz ?
70 per xtal per day
50
Appendix 1Calibration with Cosmic Rays

• Questions for simulation or analytic estimation
• What is rate of gtfew MIPs in ACD for everything
  but primary GCRs? Does this trigger add
  significantly to data volume?
• How well are CsI bars on outer edge of
  calorimeter covered by tracked GCRs?What is the
  rate of each species?
• How does rate of useful GCRs scale with geometry
  cuts?
• Cuts with CsI bars. Cuts for good TKR geometry.
• What is the shape of DE distributions for useful
  GCRs? How well can they be centroided?
• Finite width from dE/dx dependence on E0, Landau
  fluctuations, and pathlength uncertainty.
• Calibration above 10 GeV Use long-pathlength
  Fe. What is rate? How well is pathlength known?

51
Appendix 1Calibration with Cosmic Rays

• Particle fluxes
• CREME96 for 28.5 deg orbit for abundances and
  spectra.
• Conservative estimates Required GCR to pass
  through upper and lower faces of CAL.
• Particle ranges
• At 2 GeV/n in CsI, ranges of C and Fe are 440
  g/cm2 and 110 g/cm2, resp.
• All incident C will penetrate CAL (9X0 76
  g/cm2).
• All but low-energy, large-angle Fe will
  penetrate.

52
Appendix 1Calibration with Cosmic Rays

• Nuclear interactions
• Majority of GCRs suffer nuclear interactions as
  they pass through calorimeter.
• Interaction lengths
• lN,CsI 86 g/cm2
• lFe,CsI 58 g/cm2
• GCR at 45 deg traverses 100 g/cm2 of CsI
• 30 of CNO group and 20 of Fe survive without
  interacting.
• How many per day in each CsI bar?
• 1100 non-interacting CNO.
• 70 non-interacting Fe.

• Scintillation efficiency
• Light output of CsI(Tl) is not strictly
  proportional to DE for heavy ions.
• dL/dE, the light output per unit energy loss,
  decreases slowly with increasing dE/dx for heavy
  ions, but is constant for EM showers.
• dL/dE is fcn of dE/dx, rather than charge of the
  beam.
• Magnitude (in NaI!!)
• 0.9 near minimum ionizing.
• 0.3 near end of range.
• Need to measure in heavy ion beam!

53
Appendix 1Calibration with Cosmic Rays

• Calibration Uncertainty
• Need to bin GCRs by estimated DE. This is
  uncertain for following reasons
• Uncertainty in initial energy.
• DdE/dx 10 over 2 - 6 GeV/n.
• Landau fluctuations.
• sL lt 5 for CNO near 5 GeV/n.
• sL lt 5 for Fe near 5 GeV/n
• Unidentified nuclear interactions.
• p-stripping from C is hard to miss.
• p-stripping from Fe.
• DE lt 10.
• Uncertainty in dL/dE.
• Guess lt few .
• Adding in quadrature gives rms lt 20.
• With 1000 CNO per bar per day, statistical
  precision of 1 per day is achievable.

54
Appendix 2Spectral Deconvolution

• Spectral deconvolution of astrophysical sources
• Requirements
• Test emission models against the observed spectra
  of astrophysical sources.
• Need tools to turn observed counts and energy
  depositions into photons cm-2 s-1 MeV-1
• Need to account for conversion efficiency,
  livetime, and energy redistribution.
• Publish these results in refereed journals.
• These tools need to be familiar to the community
  and usable by GIs.
• What do we know?
• Spectral information comes from the ensemble of
  all photons from a source, not from individual
  photons.
• Source spectra are simple continuum shapes.
• Single power laws, power laws with breaks or
  cutoffs, etc.
• Broad pion bump, but no lines.

55
Appendix 2Spectral Deconvolution

• Resolution broadening is important for steep
  spectra.
• More-abundant low-energy photons look like
  high-energy photons.
• Observed spectrum is artificially flattened.
• So even if you make your best guess of the energy
  of each photon, you can still get the wrong
  spectral index.
• Still need to do resolution deconvolution.
• Spectral deconvolution is more than just energy
  reconstruction.
• Shower profiling helps correct observed DE into
  incident photon energy, but
• Need to account for
• resolution broadening, which can be increased by
  profiling.
• conversion efficiency (cm2)
• livetime.

56
Appendix 2Spectral Deconvolution

• Instrument response matrix.
• Conversion of incident photon flux to observed
  count spectrum.

57
Appendix 2Spectral Deconvolution

• Spectral deconvolution
• Forward-Folding Deconvolution from an ensemble of
  detected gamma rays.
• Create Instrument Response Matrix
• Transforms measured energy deposition into
  incident energy as a function of zenith and
  azimuth.
• Columns of response matrix are Greens functions
  at a large number of incident energies.
• i.e. the spectra that should be produced by
  monoenergetic beams
• Candidate incident spectrum is multiplied by the
  response matrix and compared to the observed
  spectrum.
• Parameters of the candidate spectrum are varied
  to minimize ?2.

58
Appendix 3Prototype Calorimeter Position
Resolution
Data from SLAC Oct 97 and MSU Jan 98 beam tests
Expected ADC quantization error
59
Appendix 3Prototype CalorimeterEnergy
Resolution
EM Showers
60
Appendix 3Prototype CalorimeterAngular
Resolution