February 24, 2016 Calibration

From GlueXWiki
Revision as of 18:08, 24 February 2016 by Sdobbs (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

GlueX Calibration Meeting
Wednesday, February 24, 2016
11:00 am, EST
JLab: CEBAF Center, F326

Communication Information

Remote Connection

You can connect using BlueJeans using the meeting number 630 804 895 .       (Click "Expand" to the right for more details -->):

  1. Make sure you have created a BlueJeans account via your JLab CUE account using this link:

  2. Meeting ID: 630804895
    • (you may need to type this in, depending how you connect)

  3. If connecting via Web Browser: click this link (no passcode is needed):

  4. If connecting via iOS or Android App:
    • Use your JLab e-mail address to log in and then enter the meeting ID given above to join the meeting

  5. If connecting via Phone: Dial one of the following numbers and then enter the meeting ID above and hit "#" or "##"

  6. If connecting via Polycom unit:
    • Dial 199.48.152.152 or bjn.vc
    • Enter meeting ID above
    • Use *4 to unmute

Slides

Talks can be deposited in the directory /group/halld/www/halldweb/html/talks/2016 on the JLab CUE. This directory is accessible from the web at https://halldweb.jlab.org/talks/2016/ .

Agenda

  1. Announcements
    • Offline monitoring running on incoming data
  2. Calibration Tasks
  3. Current Run
  4. Subdetector Reports
  5. Sim1 progress
  6. AOB

Minutes

  1. Announcements
    • Offline monitoring has been running on incoming data and had mostly caught up with the data on tape before lustre filesystems were taken offline.
    • The next offline monitoring run will be scheduled for about a week after the calibration train launch, depending on the progress of the jobs.
  2. Calibration Tasks
    • We discussed a few new reconstruction tasks to tackle for this spring
    • Simon is coordinating geometry updates. Some changes will be made to the XML geometry files, some parameters may be stored in CCDB when convenient.
    • For physics analyses, samples of simulated data are needed that correspond to the conditions of the data that was taken. We therefore need to update mcsmear to reflect the resolutions in current data and to look at adding run-dependent MC constants. Sean will coordinate the effort of updating the software, detector experts will be in charge of adding the CCDB constants that best reflect the conditions of their detector.
      • The primary tasks are to add dead/noisy channel support in sim-recon for detectors that do not already support this, and to update the parameters used by mcsmear. These values are listed in the wiki page linked in the agenda.
      • Sean and Dmitry will also explore loading run-dependent thresholds and other values from RCDB, and detector noise modeling will be revisited once random triggers are implemented.
      • The hardest part will likely be to devise analyses that can obtain these new CCDB constants, therefore this will be an on-going agenda item.
    • David L. pointed out that there are some lingering problems with how low-level configuration parameters are applied when reading in EVIO files. This mostly affects fADC250's. Mike S. is working on this, but it requires extensive refactoring, so he is planning to have it ready to test the new fADC250 firmware that is planned for this summer. This is expected to mainly affect the analysis of mode 8 data in the BCAL and FCAL, as it is likely the cause of differences between results with data taken in modes 7 & 8 (short & long). We are taking some data in mode 8 to check the algorithms, so we will keep an eye if this project needs to be higher priority.
    • The addition of beam photon polarization data into the analysis code was discussed at some length. What is needed for event-by-event PWAs is (1) the polarization of the photon (which is energy-dependent); (2) the uncertainty in the polarization; (3) the direction of the polarization. The information needed to obtain this can be stored in the CCDB by either some parameterization or a look-up-table based on different tagger channels. With more stable beam position being delivered by CEBAF, it is hoped that this parameterization can be just run-dependent. Curtis said that our polarization should be more stable than CLAS and Mainz due to the collimation and the stable goniometer. Justin will look at if the polarization is different for different files in the run. We probably also need a better understanding of the photon spectrum shape. [Addendum: Sean checked and the measured location of the coherent peak is being saved in the data every 10 seconds, so we can recompute the parameterization that's applied during the run if need be. We hope to not go into this complexity.]
    • Calibration Train running
      • Currently this is planned to run at 5PM Thursday, to allow for refinements to the procedure and stable farm conditions. Experience from the past week has shown that working with mode 7 data with the larger number of events per file (and more particles at higher c.m.e.) reduces the number of jobs needed for good calibrations.
      • Some tweaks to the RCDB search conditions for production runs, since most of the diamond runs were made with the daq type of "EXPERT" instead of "PHYSICS". Justin also pointed out some inconsistencies.
  3. Current Run
    • Sean said that the RCDB searches for production runs depend just on experimental conditions, but data quality hasn't been systematically checked. One of the goals of spring analysis should be to develop data quality criteria for each detector. The offline monitoring jobs generate a large number of histograms, but these results are pretty obscure to non-experts. Sean outlined a procedure and checklist that he started as an example. He'll be developing some tools to make it easy to keep track of this information. The idea would be that each detector group specify ~3-4 checks that a non-expert can perform to provide a first validation of the data, and to have this procedure in place before the Fall run.
  4. Subdetector Reports
    • FCAL - Adesh has done a few iterations of the pi0 calibration.
    • BCAL - Will has done one iteration of his pi0 calibration. More data is needed. Matt suggested to explore a skim of exclusive gamma gamma proton events. Sean will add in the p2g_hists plugin that should give us some idea of the number of events we can expect.
    • CDC - Mike has considered running millipede on the beam data with field on. The partial derivatives needed for this are tricky. Beni suggested we should take cosmics when we have some downtime.
    • FDC - Lubomir is back, no news.
    • TOF - Beni has been running his codes on multiple runs each day. The resolutions are generally stable within ~10ps, and fairly uniform over the detector. The next step is to add rhe new TDC offset parameters which should give a ~5ps improvement. Mark got an email from William saying that there were lots of changes to the new TS firmware, so it's hard to pin down exactly why the TDC shift parameter changed, but it's maybe not unsurprising that it did. Sean will run the TDC_shift plugin to check to see if the value changed from 1 for any of the new data.
    • SC - Mahmoud updated the CCDB with new timewalk corrections, and obtained an average resolution of ~265 ps. Sean suggested that he compare these results to what would be obtained if he used the timewalks from last spring. He is also looking at the effect of multiple ADC hits in a channel.
    • Firmware - Mike mentioned that he found that when running the fADC250s with NPEAK=3, sometimes the firmware outputs a pedestal without any accompanying data, that the software would turn into a hit.. He's updated the code to ignore these spurious hits.
    • TAGH - Nathan is working on data quality checks, see his logbook posts.
    • TPOL - Nathan reported that they are trying to understand the data coming from the polarimeter and optimize the DAQ settings.
    • TAGM - Alex is updating the TAGM timewalk calibration plugin to use the RF as a reference instead of the PS. Elton mentioned that Alex had said before that he got different results if he used the RF signal in the tagger crate, or the default RF signal (usually from the TOF crates), and that it should be checked to see if this is still the case.
    • PS - Alex has run the standard PS+PSC calibration codes and is studying their stability.
  5. Sim1 progress
    • Mark started production on sim1. About 5000 jobs out of ~13000 were done before the farm went down. We are saving the smeared hddm files for 5% of these jobs