20181107-Analyzer-Mtg

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

Agenda

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.

Present

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

Excused

Kent P, Ye T, Robert R