From PREX Wiki
Jump to: navigation, search

Back to Main Page >> Analyzer_Meeting

previous meeting << >> following meeting

Logistic information

 BlueJeans calling instructions:
 Toll-Free Number (U.S.&  Canada):  888-240-2560
 International toll number:         408-740-7256
 Bluejeans CODE:                  684 884 269
 Bluejeans link: https://bluejeans.com/684884269

github repository: JAPAN


  1. online plots
    • CG: working on it.
  2. vqwks from Roger: CG
    • CG: haven't tracked them down but will catch up with Steve Wood today or tomorrow
  3. regression analysis
    • PK: made the major part of the merge (to separate branch), still has compilation issues.
  4. et_bridge and deadtime: Cameron
    • CC: worked with Bob to understand some scalers and I am working on getting a better estimate for the dead time.
    • CC: plugged in a pulser for a clock and counting several signals to determine the deadtime
    • CC: talked to Carl Zimmer about some issues that I am encountering. Will work with diagnostic tools that he provided.
    • BM: right now we don’t see any deadtime (for this setup) with non-blocking and some small deadtime for blocking.
    • BM: we should build a simple analyzer (that is a bit more complicated than what we have now) to see if we get any deadtime
    • PK: could we be buffering on the crate for these small events? ie could we make the events larger? BM: the final configuration should be a couple of times larger. The readout list for the crate is as we will have it during the run.
    • PK: have you checked the network connection with blaster? BM: did it some time ago and will double check once the current experiment is done.
  5. japan plots: Cameron (see issue 22 comment with plots)
    • CC: tested that the raw channels work, that they are mapped correctly, that they two bpms are correlated,
    • PK: the raw XP already has the pedestal correction from the file, meaning that the pedestal is applied to the wire. To get the actual raw you need to plot XP.hwsum_raw
    • CC: will update the naming convention
    • BM: could we have a startup guide
    • CC: what are publish variable names? PK: it’s a means of defining the channel that would be a standard name that could be mapped to any channel. CG: so we don’t need to have anything published. PK: it is useful to have so that you can easily normalize channels in other configuration files. In most of the detector config files you have a flag that can turn off normalizations for a particular channel.


Paul K, Bob M, Cameron C, Ciprian G, Tao Y,


Kent P, Ye T, Robert R