[Halld-cal] BCAL LED Plugin

[Elton Smith]

Hi Ahmed,

Here are a few more thoughts on operation

o If I remember correctly, your plugin is processing an output skim file 
created by one of the launches. (Correct me if I am wrong). This allows 
you to run through a large time period quickly.
- The offline skims are not produced very promptly. Quick access offline 
is provided with the monitoring launches. However, they only process 5 
files from each run. Each file corresponds to 30 s worth of data, so 5 
files is only 2.5 min. We cycle through the 16 configurations in about 
16 min, so typically we would only be processing 2-3 configurations (out 
of 16) during each monitoring launch.
- Alternatively, one might be able to try skimming data online, since 
all the files are on disk before written to tape. However, since the LED 
triggers are so sparse one would need to unpack each event (recall that 
there are multiple events come in blocks from each crate) to achieve 
this goal. David mentioned that a CODA feature might allow skimming off 
events to a separate event recorder, but this is not implemented on our 
system.

-> You need to think through how the processing of the monitoring data 
would proceed, first through skims and then through your plugin and how 
this can be achieved with reasonable latency.

Cheers, Elton.

On 9/28/16 9:52 AM, Elton Smith wrote:
> 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
>