sPHENIX EMCal discussion

["Frantz, Justin" <frantz AT ohio.edu>]

Hi all,

 

Thanks everyone for the very productive EMCal meeting this past Friday.  Based on our discussion I am planning on sending the below to Chris by the requested time frame on the email copied below no later than Thursday afternoon.  Please let me know if there was anything from the discussion you feel wasn't adequately or accurately represented in the below response.  The “charge” email with the list of questions to respond to is copied at the bottom.

 

For EMCal, with input from the entire EMCal group:

 

We see a split in our calibration needs for the EMCal in two main categories based on potential frequency needed and placement in the chain for reconstruction and calibration:  I) one class of observables and calibrations that is done using the whole dataset after production, which we will focus less on in our response, since it wouldn't require necessarily formalized usage of a conditions type database, and II)  a second class of observables and calibration techniques which need done with higher frequency, that would produce correction files stored in the conditions db, that are part of the iterative chain of the data production from its earliest stages at the counting house.  A third and fourth category III and IV is mentioned also briefly below.  Category II we focus on mostly in this response.

 

The plan and workflow involved with the category II items are consistent with what has been presented in the software meeting and elsewhere over the past year, based on a hierarchy of frequencies needed to potentially follow at least the slower radiation damage effects, and possibly even faster timescale gain modifications from temperature fluctuations.   The EMCal group does agree the latter are less likely to be needed, and we have further reduced the minimum frequency we anticipate needed appropriately.  Namely the analyses here are: a pi0 tower by tower calibration done less frequently, and a possibly more frequent LED and tower energy spectra slope-based ("tower-slope")  calibration done to remove tower to tower relative and more frequent time variations.    A key point is that, as we have made known for a long time, we still are not, and cannot be certain of the frequencies needed before sPHENIX is fully installed.  However we have now settled on an updated set of frequency ranges needed that substantially reduces the maximum frequency need expected.

 

1.            What information you need to calibrate the detector (also tracks and/or electrons, jets, you want to do timing)?

 

For all of category II probes we only need calorimeter only data, including LED calibration runs.  The LED data comes both from continuous slow rate pulsing of the LEDs during data taking and also perhaps primarily from LED calibration runs that happen once per/btwn fill.  The tower-slope and pi0 TbT need samplings of the actual EMCal data.    For the tower slope the minimum data needed is 1 Million events.  For the pi0 TbT the minimum data needed is 500 Million events.   The estimate of the total events needed over the whole run equals these numbers times the frequency estimates discussed in question 3 below.

 

The category I techniques/needs include methods  which combine tracking information with calorimeter data, including electron energy scale and position corrections, high energy eta meson Escale, isolated photon ID and jet, including particle flow.

 

Finally we mention category III:  category III is some subset of category I needs techniques that we think it will be needed to have access to as early as possible, before production starts, hopefully during the startup period.  ie a full production however rough that could be used to perform an early combination of tracking and calo data and get a first look at real data to allow a jump on finalizing the category I techniques and e.g. test for performance issues for the entire chain.

 

Category IV is the pre-installation and possibly post-installation, pre-data taking cosmics based calibration corrections.  These will be for sure needed, but only once per year, and are being developed now based on cosmics data taken during construction/validation.

 

We also finalized our thoughts on whether to include timing in storage or calibrations.  We have decided to store a low precision (1Byte-precision) timing field for each hit tower.  However as this is primarily for checking extreme variations in timing like out of bunch/pileup, we don’t plan to calibrate this field in any serious way that would require consideration here.

 

 

2.            How many different calibration files you need?

 

For all EMCal calibrations techniques envisioned (the pi0/LED/tower-slope/cosmics), we expect that the files that would be actual corrections stored in the calibrations/conditions database are always the same type/format:  1 float correction factor per channel. 

 

For the category II needs we are anticipating needing two types of calibration files, one that is the product of both the LED and tower-slope method processing (combined) and another that comes from the pi0 TyT calibration method.  The format of these files can be identical, 1 float per channel.   For category IV cosmics it is also one file of the same format ~per year, 1 float per channel (possibly in addition to a single scaling factor which we ignore).

 

We mention that in order to produce these single float/channel files it will require quite a few analysis files from all methods envisioned.  In most cases the needs for these “metafiles” are mostly known, and are expected to be able to be stored (usually temporilary on a local disk) without a formalized conditions db format, so we are excluding these for now from consideration.

 

3.            Stability of constants (validity range and the basis of it)

 

LED/Tower-slope corrections: frequency needed:  once per run (per 1hr) [maximum frequency need] to once per fill (~8hrs).    Most likely more like once per fill.   However, once per run is the frequency with which we envision running the processing codes, which can be viewed as monitoring rather than calibrations, but in case gain shifts are detected in rapid successions (perhaps even if this happens temporarily) for unforeseen reasons, these processes would realistically be easiest to package per run, even if they wouldn’t necessarily be needed quite that frequently.  Similarly, even though it may not even need done as frequently as once per fill, assuming it needs done on anything close to the scale of several fills 

 

Pi0 TowerByTower:  frequency needed: Once every ~3 days to once per week.  Substantial changes in gain (15%) from rad damage over the whole run are within our current uncertainties about how much radiation dose the detector may receive, we would want to follow this well-frequently enough (with potential room to spare) to keep the calibration constant to within < 1%.   

 

4.            Calibration file size (if you have it)

 

1  float per each of the 24576 EMCal channels.  98kB (raw)   From our initial testing we can expect compression for around 20% (I had overestimated the compression in a recent software meeting).  78 kB compressed.

 

----------------------------------------------

Justin Frantz, Ph. D.  he

RHIC UEC/Diversity Working Group

Brookhaven National Lab, sPHENIX Experiment

Associate Professor

Ohio University Dept. Of Physics and Astronomy  

frantz AT ohio.edu  

646-228-2539 

PERSONAL ZOOM MEETING:  369-910-7530   Password:  1 

https://us02web.zoom.us/j/3699107530?pwd=TkZLeU1MY2d5eUpqeTJ5WUJTRHlVUT09

 

 

 

 

From: camelia mironov [mailto:cmironov AT mit.edu]

Sent: Monday, October 11, 2021 5:58 PM

To: Chris Pinkenburg <pinkenburg AT bnl.gov>; Frantz, Justin <frantz AT ohio.edu>; lajoie AT iastate.edu; woody AT bnl.gov; meganeconnors AT gmail.com

Cc: Takao Sakaguchi <takao AT bnl.gov>; Christof E Roland <cer AT mit.edu>; Stefan Bathe <stefan.bathe AT baruch.cuny.edu>

Subject: [Soft&Sim] Information needed from all calo subsystems

 

Dear ECal, iHCal, and oHCal bosses and aficionados (cc-ing also Takao and Christof as head of the Calibration TF)

 

We have been asked by (BNL+ NPPS + SDCC)_managements to come up by next Thursday with a list for what we think (at this moment) that our needs are for info/files to be stored in the condition-DB, to help with the alignment/calibration of the sub-detectors. Everybody is aware that we can not (and do not) have at this time the final/all details, but we have to present nevertheless a draft-inventory of what needs to be stored and where (based on access needs – long/short term, file-size, etc).

 

We think each subsystem should think independently of each other, because even if the methods or structure of the files might be the same, it’s likely that each subsystem will have their individual files (because of different ranges of stability, different values, etc). So while Justin can continue to coordinate this effort, we would like individual representatives to get involved and help here.

 

So this email is to ask each individual subsystem to think about it, and designate 1 person to present their thoughts in tomorrow’s Software meeting. Since we do NOT want more than 1 slide, we hope the rather late request will not get you too upset :) – we’ll use it to start the work+discussion, and then follow-up in the next week’s S&S meeting, before presenting our answer to the next management meeting.

 

====== There are 4 concrete questions we need to be addressed in the slide: ======

1.            What information you need to calibrate the detector (also tracks and/or electrons, jets, you want to do timing)?

2.            How many different calibration files you need?

3.            Stability of constants (validity range and the basis of it)

4.            Calibration file size (if you have it)

NOTE: What we need is actual file sizes, not just an abstract number how many bytes per channel are needed. At the current time a flat ntuple saved in a TFile is the likely choice. If you have other implementations, like a histogram this is perfectly fine but ASCII files are not an option. Please provide a macro which creates such an ntuple (or histogram) and fills it with values so we can generate “calibration files” for your calorimeter. Nothing fancy, just a dumb loop calling TNtuple->Fill(…).

 

 

We look forward hearing from you.

c&C