[Halld-cal] BCAL LED Plugin

[Elton Smith]

Hi Ahmed,

Thanks for providing a proposal for the BCAL LED monitoring plugin. I 
have some general comments and then some specific suggestions to the plots.

General:

o I think we should use this plugin, at least initially, as a "fast" 
offline monitor. In order for it to be useful online, we would need to 
provide the shift personnel specific instructions on what to do if 
"abnormal" situations develop, as in plot shown in your example R11435. 
At the moment all I can think to do in this situation is to "call the 
expert" to investigate. Certainly, I would not stop data taking or 
modify bias voltages or other settings on the BCAL, which are the only 
tools we have online to modify running conditions. We should talk to 
Paul or others in the offline to see where it would best fit into the 
routine launches.

o For offline, these few histograms are useful as global summaries, but 
one immediately would like to see the same histograms plotted for 
different quadrants separately instead of all together on a single plot.
- If the histograms are available in root, one would be able to plot 
projections, etc to further diagnose any problems.
- The next step in diagnosing the information would be to investigate 
the time history through the problematic runs to see if there are any 
correlations with EPICs variables such as temperature, chiller 
parameters. Does the problem persist across runs?
- For example in the top right plot of R11435, we want to check that the 
"gaps" in the black data indeed lie on the line at unity. They could be 
above or below the limits of the plots. How do we know that all data are 
within the plotted limits? Again access to the histogram itself would be 
useful.

o What should we conclude regarding outliers on your plots. For example 
on the "good" run R11454, there is a channel ID~650 with a ratio of 
about 0.93 outside the main band. There was an bad TDC and noisy FADC 
(see Will's talk at the collaboration meeting 
http://argus.phys.uregina.ca/gluex/DocDB/0030/003025/001/BCAL_ClusteringGain_update_may10.pdf, 
p. 2). We need to think at which point we can would/should eliminate 
cells from the analysis based on their performance as determined, for 
example, by some of these monitoring distributions.

o As far as where to store the references (CCDB or root files), I would 
defer to Sean for advice on that technical issue.

o You should produce a writeup of what you have done and precise 
definitions of variables used. For example what is "well behaved"? What 
is the list of runs used? How did the monitor work over the entire 
spring run. You showed some plots at the last meeting that addressed 
this, but a writeup would put it all together and make it easier to find.

Specifics:

o title: 6v -> 6V. Y-axis label should be peak/mean. I suggest for the 
X-axis, you spell out what channel id means in the title, e.g. channel 
ID (16*(module-1) + 4*(layer-1) + (sector-1))

Thanks for summarizing the procedure. Cheers, Elton.

On 9/27/16 5:48 PM, Ahmed Foda wrote:
>
>
> Hi,
>
> I believe we have a general proposal of how we want the BCAL LED 
> plugin to work. Please review and provide feedback.
>
> 1- I believe the suggestion was to use averages obtained from spring 
> 2016 "well behaved" data as reference was accepted. Currently I am 
> using this method which generates a single root file that which I use 
> as input for the root plotting macro. The other possibility is to 
> implement these reference values in the CCDB. Those averages can also 
> be generated from the fall 2016 data and the root file and CCDB updated.
>
> 2- For simplicity while monitoring, the shift Leader/Worker would see 
> one page with 4 histograms representing ratios vs channel ID. Each 
> histogram represents a bias/side combination (e.g. 6v upstream, 6.25 
> downstream ..) and includes 4 colors for the 4 different sectors. 
> Kindly find example plot for well behaved and quadrants failing 
> (namely quadrants 1,2 & 4 in 6v downstream sector 1) runs attached. I 
> suggest keeping the output root files containing the absolute values, 
> for a more in-depth examination if necessary.
>
> 3- I suggest adding 64 boolean variables to represent quadrant 
> failures (16 configurations, 4 quadrants each) for more convenient 
> study in the future. We should discuss monitoring the frequency of 
> these quadrant effects within each run and across all runs.
>
> Cheers, Ahmed.
>
>
>
> _______________________________________________
> Halld-cal mailing list
> Halld-cal at jlab.org
> https://mailman.jlab.org/mailman/listinfo/halld-cal