Difference between revisions of "July 30, 2014 Calibration"

From GlueXWiki
Jump to: navigation, search
(Created page with "__TOC__ GlueX Calibration Meeting<br> Wednesday, July 30, 2014<br> 11:00 am, EDT<br> JLab: CEBAF Center, F326<br> == Connection Using Bluejeans == # To join via Polycom room sy...")
 
(Minutes)
 
(3 intermediate revisions by 2 users not shown)
Line 19: Line 19:
 
# Announcements
 
# Announcements
 
# Status Update
 
# Status Update
# Tracking   
+
# Tracking  [http://www.jlab.org/Hall-D/detector/fdc/DAQ/FirstTrack_3D_DTcorrected.pdf First FDC track tru All 24 packages], [http://www.jlab.org/Hall-D/detector/fdc/DAQ/FDC_Inter3D.pdf interaction within FDC]
 
# Calorimetry
 
# Calorimetry
 
# Other systems
 
# Other systems
 
# Simulations and Calibrations
 
# Simulations and Calibrations
 +
 +
== Minutes ==
 +
 +
Attending: Sean (NU); Simon, Lubomir, Beni, Mark I., David L., Mike S. (JLab); Curtis (CMU)
 +
 +
# Announcements
 +
#* Simon is in the process process of cleaning up the DFDCHit class.
 +
# Status Update
 +
#* Sean has been working to update the rawevent plugin to be consistent with the current state of the fADC/TDC firmware, so that people can start testing low-level calibrations with simulated events.  The current plugin works fine for the calorimeters, but there are some problems with tracking - this may be partially due to the translation table problems noted by Lubomir below.  The next steps are to move the scale factors into the CCDB, so that a consistent set of factors is used to create the EVIO files and to read them back in, and to apply pedestal/time offsets in the rawevent plugin.
 +
#* David described the current status of hit-by-hit pedestal information. fADC250's currently report a pedestal based on the first 4 samples of a signal.  The fADC125's don't report a pedestal, but this feature is planned for the next version of the firmware.  Eventually, the window for the pedestal calculation will be a parameter that can be set in the firmware. The values parameter could then be worked into the data stream for use in reconstruction. Beni suggested that we should look into rejecting pedestals that lie outside of some range, perhaps because they catch the tail of another hit. Mark suggested that since the window size would be used in offline analysis, we should store it in the CCDB.  From discussion, it sounds like careful planning will be able to put these parameters in the data stream without too many changes or much increase in the data footprint.
 +
#* Beni mentioned that when he was taking data to determine the CDC/FDC pedestals, one of the ROCs died during data taking.  He suggested that some sort of monitoring and/or sanity checks should be done at some point in the data processing chain.  There was agreement that this was a good idea, and some discussion of how it should be done.  It might be better to do this later in the process, say just before the L3 trigger, so that we don't have to worry about disentagling events during higher luminosity data taking.  [nb. there was more discussion on this and the next topic at the Online meeting in the afternoon.]
 +
#* David described another issue for online data processing, where the F1TDC would continually report and put their headers in the data stream, even when they didn't have any data to read out.  This problem was originally noticed a long time ago by Elliott.  Stripping out the unneeded headers would reduce the data footprint.
 +
#* Sean floated the question of whether the ADC/TDC time offsets should be stored in the CCDB in the natural units of the ADC/TDC modules or in physical units (ns).  The consensus was to keep using natural units.
 +
# Tracking
 +
#* Lubomir showed displays of two events that went all the way through the FDC - 1 straight through and another that seemed to interact in the second package.  The rate corresponds to ~1 event/day.  These events have already been useful for debugging, for instance, in the Translation Table, some of the wires had wrong channel numbers and some of the cathodes were incorrectly mapped.  David offered to fix these in the official table.
 +
#* Simon has been working on reading in these FDC hits into the DANA framework.  He has also had success in reading in the CDC hits and using them for alignment.  Preliminary results look promising, but more data is needed.
 +
#* Beni said that the cosmic data rate is limited by the noise, which seems to be coming from the CAEN HV supplies.  A plan to address this is being worked on.
 +
# Calorimetry
 +
#* Sean has been following the meetings of this group.  He has also been working with Mark Dalton on procedures for loading BCAL constants.
 +
#* Beni mentioned that he had been seeing some variations in the fADC pedestals as a function of time.  It would be useful to hear the experiences of the FCAL/BCAL groups.

Latest revision as of 13:39, 31 July 2014

GlueX Calibration Meeting
Wednesday, July 30, 2014
11:00 am, EDT
JLab: CEBAF Center, F326

Connection Using Bluejeans

  1. To join via Polycom room system go to the IP Address: 199.48.152.152 (bjn.vc) and enter the meeting ID: 630804895.
  2. To join via a Web Browser, go to the page [1] https://bluejeans.com/630804895.
  3. To join via phone, use one of the following numbers and the Conference ID: 630804895
    • 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
  5. More information on connecting to bluejeans is available.

Agenda

  1. Announcements
  2. Status Update
  3. Tracking First FDC track tru All 24 packages, interaction within FDC
  4. Calorimetry
  5. Other systems
  6. Simulations and Calibrations

Minutes

Attending: Sean (NU); Simon, Lubomir, Beni, Mark I., David L., Mike S. (JLab); Curtis (CMU)

  1. Announcements
    • Simon is in the process process of cleaning up the DFDCHit class.
  2. Status Update
    • Sean has been working to update the rawevent plugin to be consistent with the current state of the fADC/TDC firmware, so that people can start testing low-level calibrations with simulated events. The current plugin works fine for the calorimeters, but there are some problems with tracking - this may be partially due to the translation table problems noted by Lubomir below. The next steps are to move the scale factors into the CCDB, so that a consistent set of factors is used to create the EVIO files and to read them back in, and to apply pedestal/time offsets in the rawevent plugin.
    • David described the current status of hit-by-hit pedestal information. fADC250's currently report a pedestal based on the first 4 samples of a signal. The fADC125's don't report a pedestal, but this feature is planned for the next version of the firmware. Eventually, the window for the pedestal calculation will be a parameter that can be set in the firmware. The values parameter could then be worked into the data stream for use in reconstruction. Beni suggested that we should look into rejecting pedestals that lie outside of some range, perhaps because they catch the tail of another hit. Mark suggested that since the window size would be used in offline analysis, we should store it in the CCDB. From discussion, it sounds like careful planning will be able to put these parameters in the data stream without too many changes or much increase in the data footprint.
    • Beni mentioned that when he was taking data to determine the CDC/FDC pedestals, one of the ROCs died during data taking. He suggested that some sort of monitoring and/or sanity checks should be done at some point in the data processing chain. There was agreement that this was a good idea, and some discussion of how it should be done. It might be better to do this later in the process, say just before the L3 trigger, so that we don't have to worry about disentagling events during higher luminosity data taking. [nb. there was more discussion on this and the next topic at the Online meeting in the afternoon.]
    • David described another issue for online data processing, where the F1TDC would continually report and put their headers in the data stream, even when they didn't have any data to read out. This problem was originally noticed a long time ago by Elliott. Stripping out the unneeded headers would reduce the data footprint.
    • Sean floated the question of whether the ADC/TDC time offsets should be stored in the CCDB in the natural units of the ADC/TDC modules or in physical units (ns). The consensus was to keep using natural units.
  3. Tracking
    • Lubomir showed displays of two events that went all the way through the FDC - 1 straight through and another that seemed to interact in the second package. The rate corresponds to ~1 event/day. These events have already been useful for debugging, for instance, in the Translation Table, some of the wires had wrong channel numbers and some of the cathodes were incorrectly mapped. David offered to fix these in the official table.
    • Simon has been working on reading in these FDC hits into the DANA framework. He has also had success in reading in the CDC hits and using them for alignment. Preliminary results look promising, but more data is needed.
    • Beni said that the cosmic data rate is limited by the noise, which seems to be coming from the CAEN HV supplies. A plan to address this is being worked on.
  4. Calorimetry
    • Sean has been following the meetings of this group. He has also been working with Mark Dalton on procedures for loading BCAL constants.
    • Beni mentioned that he had been seeing some variations in the fADC pedestals as a function of time. It would be useful to hear the experiences of the FCAL/BCAL groups.