Difference between revisions of "Jul 30, 2015 Calorimetry"

From GlueXWiki
Jump to: navigation, search
(Minutes)
 
(7 intermediate revisions by the same user not shown)
Line 47: Line 47:
 
= Minutes =
 
= Minutes =
  
''Attendees:
+
''Attendees: Manuel, Jon, Adesh, David, Elton (JLab); Will, Mike (CMU); George, Christina (Athens); Zisis, Noemi, Ahmed, Tegan (UofR)
  
 
# Announcements
 
# Announcements
Line 55: Line 55:
 
#* Solenoid cooldown and ramp up mid August  
 
#* Solenoid cooldown and ramp up mid August  
 
# FCAL Update
 
# FCAL Update
 +
## Bases, firmware updates (Jon)
 +
##* Hovanes is checking new firmware updates
 +
##* Find bad bases in the detector that are corrupting other bases during bootloader uploads.
 +
##* About 40 bad pmt bases found in the detector. Manuel: This problem encountered during installation and no fix determined, but Dan might be able to shed some light on it.
 +
##* Even after reprogramming, the "bad" bases remain bad after reprograming.
 +
##* Bad bases will be replaced next week and shipped back to IU for Paul to investigate problem.
 +
## Analysis
 +
##* Adesh: Changing focus to work on simulation with the goal to find the expected resolution from Monte Carlo.
 +
##* Jon: Still plans to investigate FCAL efficiencies using various data samples including: omega-> pi0 gamma, omega-> pi+pi-pi0, pi0pi0p exclusive, pi0 p exclusive.
 
# BCAL Update
 
# BCAL Update
#* [https://halldweb1.jlab.org/wiki/images/e/ea/BCAL_EFF_Calorimetry_July302015.pdf BCAL Efficiency (Ahmed)]
+
## [https://halldweb1.jlab.org/wiki/images/e/ea/BCAL_EFF_Calorimetry_July302015.pdf BCAL Efficiency (Ahmed)]
 +
##* There have been some indications for phi dependence in the efficiencies, and discrepancies in layer 4
 +
##* Christine: How to undertand efficiencies for layer 4 if tracks may stop in layer 3. Suggest selecting high energy tracks as a way of enhancing the probability for penetrating to layer 4.
 +
##* David: Notes that the emulation code using mode 8 does not duplicate what is in the firmware for mode 7. Plans to submit some changes to the code to make them more compatible.
 +
##* Elton: Layer 4 will be complicated to understand. Suggest that the focus be on differences between mode 7 and mode 8 efficiencies for layers 1-3.
 +
##* George: Comments that the veff determination shows a layer dependence, not a phi dependence except for cosmics in the bottom half of the detector.
 +
##* Will: does the phi modulation without energy selection in FCAL look the same as with an energy cut? Not yet investigated this.
 +
## Time-walk corrections (Mike)
 +
##* Looking at run R2931, plotted ADC-TDC times as a function of peak value.
 +
##* May need to update data structures for peak information if this is to be used for analysis. Elton: Should consult Mark regarding these changes.
 +
##* Plots show distributions roughly consistent  with expectations.
 +
##* Fitting data to time-walk functional form finds that it works well for most of the range of peak values but fails for large values.
 +
##* After corrections, the  width of the distribution is about 300 ps.
 +
##* Mike will make code available on a branch that is accessible.
 +
##* Noemi can take a look at it and use it to explore optimizing fitting functions and procedures.
 
# [[Calorimetry F250 Firmware]]  Discussions
 
# [[Calorimetry F250 Firmware]]  Discussions
# Reconstruction and Simulation
+
#* Elton summarized current discussion on the f250 firmware
 +
#* The volume of "content" (ADC and TDC information) is small compared to headers and other timing marker words
 +
#* The current thought is to include both integral and peak into the data stream, as well as timing information
 +
#* Proposals have been made for the data format and they are under discussion
 +
#* The plan is to have a draft document in about a month that can be circulated more widely including to members of the fast electronics group. Ideally, the new firmware can be implemented by the time of the fall run.
 +
# Reconstruction and Simulation (Tegan)
 +
#* Added tdc to the digiHit information in the simulation (similar to what was already included for adc hits)
 +
#* Found that hdgeant was outputting negative times and an adjustment was needed to make them positive, as raw data only has positive integers.
 +
#* Code was tested yesterday and plans to push changes to git soon.
 +
#* Will: Considerations for eliminating negative hits from the clusterizer are under discussion.
 +
# Git
 +
#* Will encountered some problems with git branches and forks.
 +
#* David: Suggested process is to check in changes to a local branch, push to main (master) repository, then send a pull request. See [[Instructions for Working with GlueX Git Repositories]]
 +
#* For general information about git conversion see [[GlueX Offline FAQ#Git]] and [[Conversion from Subversion to Git]]
 +
#* Suggestions/comments regarding git should be sent to Mark Ito for dissemination through offline wiki pages or other documentation.
 
# Calibration
 
# Calibration
 
#* [[Media:Eff_speed.pptx | BCAL - Effective Speed of Light]] (George)
 
#* [[Media:Eff_speed.pptx | BCAL - Effective Speed of Light]] (George)
 +
#* Writing a report with work to date and it is about 80% complete
 +
#* At the moment the constants of veff converge for different layers for the cosmic data and a cut of delta ztrk-zshower < 20 cm.
 +
#* Studies are underway to understand the selection, although plots show that there is no significant bias as a function of z. Plan is to try to reject outliers based on better informed criteria.
 +
#* Currently the value for veff in ccdb is 16.75 cm/ns. The improved Regina result of 17 cm/ns has not been implemented yet. The new analysis converges on a number with is close to 17 cm/ns.
 +
#* Mike: Suggest to check in the new constants into a local file and check how the program behaves with the new constants.
 +
#* Assuming no anomalies are found, the constants can be submitted into ccdb. Zisis: Give everyone advanced notice including Sean.
 +
#* Tegan: Notes that the new constants should be added to the simulation. Elton: Indeed, but for the moment it is important to have consistency between generated and reconstructed simulation.
 
# Any other business
 
# Any other business
 
# Testing
 
# Testing

Latest revision as of 14:29, 30 July 2015

Video Conferencing Information

Meeting Time: 11 a.m.

  1. To join via a Web Browser, go to the page [1] https://bluejeans.com/907185247.
  2. To join via Polycom room system go to the IP Address: 199.48.152.152 (bjn.vc) and enter the meeting ID: 907185247.
  3. To join via phone, use one of the following numbers and the Conference ID: 907185247.
    • US or Canada: +1 408 740 7256 or
    • US or Canada: +1 888 240 2560
  4. Upon connection all microphones are automatically muted. To unmute your mike on a Polycom or equivalent unit, enter *4. Unmuting on a computer is trivial as there is a microphone button than can be clicked.
  5. More information on connecting to bluejeans is available.

Participant Direct Lines

  • JLab Phone: in CC F326 is 757-269-6460 (usual room)
  • JLab Phone in CC L207 is 757-269-7084
  • Phone in the Regina Video-conference Suite is 306-585-4204
  • Athens Phone: in Christina's office is 011-30-210-727-6947

Action Items

  1. Change BCAL and FCAL coordinates use the global coordinate system (not the target center). Action of this item is under discussion

References

  1. FCAL HDFCAL log book
  2. BCAL HDBCAL log book
  3. BCAL Action Items and Working Tasks

Tentative Agenda

  1. Announcements
  2. Action Items
  3. Run preparations
  4. FCAL Update
  5. BCAL Update
  6. Calorimetry F250 Firmware Discussions
  7. Reconstruction and Simulation
  8. Calibration
  9. Any other business
  10. Testing

Minutes

Attendees: Manuel, Jon, Adesh, David, Elton (JLab); Will, Mike (CMU); George, Christina (Athens); Zisis, Noemi, Ahmed, Tegan (UofR)

  1. Announcements
  2. Action Items
  3. Run preparations
  4. FCAL Update
    1. Bases, firmware updates (Jon)
      • Hovanes is checking new firmware updates
      • Find bad bases in the detector that are corrupting other bases during bootloader uploads.
      • About 40 bad pmt bases found in the detector. Manuel: This problem encountered during installation and no fix determined, but Dan might be able to shed some light on it.
      • Even after reprogramming, the "bad" bases remain bad after reprograming.
      • Bad bases will be replaced next week and shipped back to IU for Paul to investigate problem.
    2. Analysis
      • Adesh: Changing focus to work on simulation with the goal to find the expected resolution from Monte Carlo.
      • Jon: Still plans to investigate FCAL efficiencies using various data samples including: omega-> pi0 gamma, omega-> pi+pi-pi0, pi0pi0p exclusive, pi0 p exclusive.
  5. BCAL Update
    1. BCAL Efficiency (Ahmed)
      • There have been some indications for phi dependence in the efficiencies, and discrepancies in layer 4
      • Christine: How to undertand efficiencies for layer 4 if tracks may stop in layer 3. Suggest selecting high energy tracks as a way of enhancing the probability for penetrating to layer 4.
      • David: Notes that the emulation code using mode 8 does not duplicate what is in the firmware for mode 7. Plans to submit some changes to the code to make them more compatible.
      • Elton: Layer 4 will be complicated to understand. Suggest that the focus be on differences between mode 7 and mode 8 efficiencies for layers 1-3.
      • George: Comments that the veff determination shows a layer dependence, not a phi dependence except for cosmics in the bottom half of the detector.
      • Will: does the phi modulation without energy selection in FCAL look the same as with an energy cut? Not yet investigated this.
    2. Time-walk corrections (Mike)
      • Looking at run R2931, plotted ADC-TDC times as a function of peak value.
      • May need to update data structures for peak information if this is to be used for analysis. Elton: Should consult Mark regarding these changes.
      • Plots show distributions roughly consistent with expectations.
      • Fitting data to time-walk functional form finds that it works well for most of the range of peak values but fails for large values.
      • After corrections, the width of the distribution is about 300 ps.
      • Mike will make code available on a branch that is accessible.
      • Noemi can take a look at it and use it to explore optimizing fitting functions and procedures.
  6. Calorimetry F250 Firmware Discussions
    • Elton summarized current discussion on the f250 firmware
    • The volume of "content" (ADC and TDC information) is small compared to headers and other timing marker words
    • The current thought is to include both integral and peak into the data stream, as well as timing information
    • Proposals have been made for the data format and they are under discussion
    • The plan is to have a draft document in about a month that can be circulated more widely including to members of the fast electronics group. Ideally, the new firmware can be implemented by the time of the fall run.
  7. Reconstruction and Simulation (Tegan)
    • Added tdc to the digiHit information in the simulation (similar to what was already included for adc hits)
    • Found that hdgeant was outputting negative times and an adjustment was needed to make them positive, as raw data only has positive integers.
    • Code was tested yesterday and plans to push changes to git soon.
    • Will: Considerations for eliminating negative hits from the clusterizer are under discussion.
  8. Git
  9. Calibration
    • BCAL - Effective Speed of Light (George)
    • Writing a report with work to date and it is about 80% complete
    • At the moment the constants of veff converge for different layers for the cosmic data and a cut of delta ztrk-zshower < 20 cm.
    • Studies are underway to understand the selection, although plots show that there is no significant bias as a function of z. Plan is to try to reject outliers based on better informed criteria.
    • Currently the value for veff in ccdb is 16.75 cm/ns. The improved Regina result of 17 cm/ns has not been implemented yet. The new analysis converges on a number with is close to 17 cm/ns.
    • Mike: Suggest to check in the new constants into a local file and check how the program behaves with the new constants.
    • Assuming no anomalies are found, the constants can be submitted into ccdb. Zisis: Give everyone advanced notice including Sean.
    • Tegan: Notes that the new constants should be added to the simulation. Elton: Indeed, but for the moment it is important to have consistency between generated and reconstructed simulation.
  10. Any other business
  11. Testing