<div dir="ltr"><div dir="ltr" class="gmail_msg">Hi all,</div><div dir="ltr" class="gmail_msg"><br></div><div dir="ltr" class="gmail_msg">Sorry for the late response on this, it seems to have slipped through a crack on my end.</div><div dir="ltr" class="gmail_msg"><br></div><div dir="ltr" class="gmail_msg">I have a couple comments on the practical issues that Elton brought up:</div><div dir="ltr" class="gmail_msg"><br></div><div dir="ltr" class="gmail_msg">- In this run, the offline skims will start production as files hit the tape library.  So while the monitoring launches will provide a quick look at the data, the full data set will be available with a quicker turnaround than in the spring.  I could also run this plugin in parallel with the skim jobs to obtain the first results more quickly.</div><div dir="ltr" class="gmail_msg"><br></div><div dir="ltr" class="gmail_msg">- I am still a little confused about what the reference values are used for - is what's plotted in Ahmed's attached plots the ratio between the measured and reference values?  I can see two ways of dealing with such values:</div><div dir="ltr" class="gmail_msg"><br></div><div dir="ltr" class="gmail_msg">1) We can store the reference values in the CCDB, load them in the plugin, and directly create the two types of plots (raw and ratio), in the plugin itself.</div><div dir="ltr" class="gmail_msg"><br></div><div dir="ltr" class="gmail_msg">2) We can store the reference ROOT file in some web-accessible location, store this location in the CCDB, and produce a script that will automatically download the file at which point it could be passed to the ROOT script that makes the plots.  This is similar to JANA's "resource" capability that is used to deliver information like the magnetic field maps.</div><div dir="ltr" class="gmail_msg"><br></div><div dir="ltr" class="gmail_msg">Cheers,<br>Sean<br class="gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg"><div dir="ltr" class="gmail_msg">On Wed, Sep 28, 2016 at 10:46 AM Elton Smith <<a href="mailto:elton@jlab.org" class="gmail_msg" target="_blank">elton@jlab.org</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Ahmed,<br class="gmail_msg"><br><br class="gmail_msg"><br>Here are a few more thoughts on operation<br class="gmail_msg"><br><br class="gmail_msg"><br>o If I remember correctly, your plugin is processing an output skim file<br class="gmail_msg"><br>created by one of the launches. (Correct me if I am wrong). This allows<br class="gmail_msg"><br>you to run through a large time period quickly.<br class="gmail_msg"><br>- The offline skims are not produced very promptly. Quick access offline<br class="gmail_msg"><br>is provided with the monitoring launches. However, they only process 5<br class="gmail_msg"><br>files from each run. Each file corresponds to 30 s worth of data, so 5<br class="gmail_msg"><br>files is only 2.5 min. We cycle through the 16 configurations in about<br class="gmail_msg"><br>16 min, so typically we would only be processing 2-3 configurations (out<br class="gmail_msg"><br>of 16) during each monitoring launch.<br class="gmail_msg"><br>- Alternatively, one might be able to try skimming data online, since<br class="gmail_msg"><br>all the files are on disk before written to tape. However, since the LED<br class="gmail_msg"><br>triggers are so sparse one would need to unpack each event (recall that<br class="gmail_msg"><br>there are multiple events come in blocks from each crate) to achieve<br class="gmail_msg"><br>this goal. David mentioned that a CODA feature might allow skimming off<br class="gmail_msg"><br>events to a separate event recorder, but this is not implemented on our<br class="gmail_msg"><br>system.<br class="gmail_msg"><br><br class="gmail_msg"><br>-> You need to think through how the processing of the monitoring data<br class="gmail_msg"><br>would proceed, first through skims and then through your plugin and how<br class="gmail_msg"><br>this can be achieved with reasonable latency.<br class="gmail_msg"><br><br class="gmail_msg"><br>Cheers, Elton.<br class="gmail_msg"><br><br class="gmail_msg"><br>On 9/28/16 9:52 AM, Elton Smith wrote:<br class="gmail_msg"><br>> Hi Ahmed,<br class="gmail_msg"><br>><br class="gmail_msg"><br>> Thanks for providing a proposal for the BCAL LED monitoring plugin. I<br class="gmail_msg"><br>> have some general comments and then some specific suggestions to the<br class="gmail_msg"><br>> plots.<br class="gmail_msg"><br>><br class="gmail_msg"><br>> General:<br class="gmail_msg"><br>><br class="gmail_msg"><br>> o I think we should use this plugin, at least initially, as a "fast"<br class="gmail_msg"><br>> offline monitor. In order for it to be useful online, we would need to<br class="gmail_msg"><br>> provide the shift personnel specific instructions on what to do if<br class="gmail_msg"><br>> "abnormal" situations develop, as in plot shown in your example<br class="gmail_msg"><br>> R11435. At the moment all I can think to do in this situation is to<br class="gmail_msg"><br>> "call the expert" to investigate. Certainly, I would not stop data<br class="gmail_msg"><br>> taking or modify bias voltages or other settings on the BCAL, which<br class="gmail_msg"><br>> are the only tools we have online to modify running conditions. We<br class="gmail_msg"><br>> should talk to Paul or others in the offline to see where it would<br class="gmail_msg"><br>> best fit into the routine launches.<br class="gmail_msg"><br>><br class="gmail_msg"><br>> o For offline, these few histograms are useful as global summaries,<br class="gmail_msg"><br>> but one immediately would like to see the same histograms plotted for<br class="gmail_msg"><br>> different quadrants separately instead of all together on a single plot.<br class="gmail_msg"><br>> - If the histograms are available in root, one would be able to plot<br class="gmail_msg"><br>> projections, etc to further diagnose any problems.<br class="gmail_msg"><br>> - The next step in diagnosing the information would be to investigate<br class="gmail_msg"><br>> the time history through the problematic runs to see if there are any<br class="gmail_msg"><br>> correlations with EPICs variables such as temperature, chiller<br class="gmail_msg"><br>> parameters. Does the problem persist across runs?<br class="gmail_msg"><br>> - For example in the top right plot of R11435, we want to check that<br class="gmail_msg"><br>> the "gaps" in the black data indeed lie on the line at unity. They<br class="gmail_msg"><br>> could be above or below the limits of the plots. How do we know that<br class="gmail_msg"><br>> all data are within the plotted limits? Again access to the histogram<br class="gmail_msg"><br>> itself would be useful.<br class="gmail_msg"><br>><br class="gmail_msg"><br>> o What should we conclude regarding outliers on your plots. For<br class="gmail_msg"><br>> example on the "good" run R11454, there is a channel ID~650 with a<br class="gmail_msg"><br>> ratio of about 0.93 outside the main band. There was an bad TDC and<br class="gmail_msg"><br>> noisy FADC (see Will's talk at the collaboration meeting<br class="gmail_msg"><br>> <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__argus.phys.uregina.ca_gluex_DocDB_0030_003025_001_BCAL-5FClusteringGain-5Fupdate-5Fmay10.pdf&d=CwICAg&c=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=y4ZD58I4nPR6tZqjerSGt-WlWVAhqa3FHDMXqQ_5aUc&m=yXEh1cAFzAHLirDbd8LBVxc84XcRZ9hACp_ytIMb8pE&s=BzoDzc7kLzAeLZjgjD0pT1MMnZHokUoh2D1wykR5us8&e=" rel="noreferrer" class="gmail_msg" target="_blank">https://urldefense.proofpoint.com/v2/url?u=http-3A__argus.phys.uregina.ca_gluex_DocDB_0030_003025_001_BCAL-5FClusteringGain-5Fupdate-5Fmay10.pdf&d=CwICAg&c=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=y4ZD58I4nPR6tZqjerSGt-WlWVAhqa3FHDMXqQ_5aUc&m=yXEh1cAFzAHLirDbd8LBVxc84XcRZ9hACp_ytIMb8pE&s=BzoDzc7kLzAeLZjgjD0pT1MMnZHokUoh2D1wykR5us8&e=</a> ,<br class="gmail_msg"><br>> p. 2). We need to think at which point we can would/should eliminate<br class="gmail_msg"><br>> cells from the analysis based on their performance as determined, for<br class="gmail_msg"><br>> example, by some of these monitoring distributions.<br class="gmail_msg"><br>><br class="gmail_msg"><br>> o As far as where to store the references (CCDB or root files), I<br class="gmail_msg"><br>> would defer to Sean for advice on that technical issue.<br class="gmail_msg"><br>><br class="gmail_msg"><br>> o You should produce a writeup of what you have done and precise<br class="gmail_msg"><br>> definitions of variables used. For example what is "well behaved"?<br class="gmail_msg"><br>> What is the list of runs used? How did the monitor work over the<br class="gmail_msg"><br>> entire spring run. You showed some plots at the last meeting that<br class="gmail_msg"><br>> addressed this, but a writeup would put it all together and make it<br class="gmail_msg"><br>> easier to find.<br class="gmail_msg"><br>><br class="gmail_msg"><br>> Specifics:<br class="gmail_msg"><br>><br class="gmail_msg"><br>> o title: 6v -> 6V. Y-axis label should be peak/mean. I suggest for the<br class="gmail_msg"><br>> X-axis, you spell out what channel id means in the title, e.g. channel<br class="gmail_msg"><br>> ID (16*(module-1) + 4*(layer-1) + (sector-1))<br class="gmail_msg"><br>><br class="gmail_msg"><br>> Thanks for summarizing the procedure. Cheers, Elton.<br class="gmail_msg"><br>><br class="gmail_msg"><br>> On 9/27/16 5:48 PM, Ahmed Foda wrote:<br class="gmail_msg"><br>>><br class="gmail_msg"><br>>><br class="gmail_msg"><br>>> Hi,<br class="gmail_msg"><br>>><br class="gmail_msg"><br>>> I believe we have a general proposal of how we want the BCAL LED<br class="gmail_msg"><br>>> plugin to work. Please review and provide feedback.<br class="gmail_msg"><br>>><br class="gmail_msg"><br>>> 1- I believe the suggestion was to use averages obtained from spring<br class="gmail_msg"><br>>> 2016 "well behaved" data as reference was accepted. Currently I am<br class="gmail_msg"><br>>> using this method which generates a single root file that which I use<br class="gmail_msg"><br>>> as input for the root plotting macro. The other possibility is to<br class="gmail_msg"><br>>> implement these reference values in the CCDB. Those averages can also<br class="gmail_msg"><br>>> be generated from the fall 2016 data and the root file and CCDB updated.<br class="gmail_msg"><br>>><br class="gmail_msg"><br>>> 2- For simplicity while monitoring, the shift Leader/Worker would see<br class="gmail_msg"><br>>> one page with 4 histograms representing ratios vs channel ID. Each<br class="gmail_msg"><br>>> histogram represents a bias/side combination (e.g. 6v upstream, 6.25<br class="gmail_msg"><br>>> downstream ..) and includes 4 colors for the 4 different sectors.<br class="gmail_msg"><br>>> Kindly find example plot for well behaved and quadrants failing<br class="gmail_msg"><br>>> (namely quadrants 1,2 & 4 in 6v downstream sector 1) runs attached. I<br class="gmail_msg"><br>>> suggest keeping the output root files containing the absolute values,<br class="gmail_msg"><br>>> for a more in-depth examination if necessary.<br class="gmail_msg"><br>>><br class="gmail_msg"><br>>> 3- I suggest adding 64 boolean variables to represent quadrant<br class="gmail_msg"><br>>> failures (16 configurations, 4 quadrants each) for more convenient<br class="gmail_msg"><br>>> study in the future. We should discuss monitoring the frequency of<br class="gmail_msg"><br>>> these quadrant effects within each run and across all runs.<br class="gmail_msg"><br>>><br class="gmail_msg"><br>>> Cheers, Ahmed.<br class="gmail_msg"><br>>><br class="gmail_msg"><br>>><br class="gmail_msg"><br>>><br class="gmail_msg"><br>>> _______________________________________________<br class="gmail_msg"><br>>> Halld-cal mailing list<br class="gmail_msg"><br>>> <a href="mailto:Halld-cal@jlab.org" class="gmail_msg" target="_blank">Halld-cal@jlab.org</a><br class="gmail_msg"><br>>> <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__mailman.jlab.org_mailman_listinfo_halld-2Dcal&d=CwICAg&c=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=y4ZD58I4nPR6tZqjerSGt-WlWVAhqa3FHDMXqQ_5aUc&m=yXEh1cAFzAHLirDbd8LBVxc84XcRZ9hACp_ytIMb8pE&s=-nNUG0o4KnJPZ4VmqWAQxVFapOeSoDqCZ0lUR9bNw98&e=" rel="noreferrer" class="gmail_msg" target="_blank">https://urldefense.proofpoint.com/v2/url?u=https-3A__mailman.jlab.org_mailman_listinfo_halld-2Dcal&d=CwICAg&c=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=y4ZD58I4nPR6tZqjerSGt-WlWVAhqa3FHDMXqQ_5aUc&m=yXEh1cAFzAHLirDbd8LBVxc84XcRZ9hACp_ytIMb8pE&s=-nNUG0o4KnJPZ4VmqWAQxVFapOeSoDqCZ0lUR9bNw98&e=</a><br class="gmail_msg"><br>><br class="gmail_msg"><br><br class="gmail_msg"><br>_______________________________________________<br class="gmail_msg"><br>Halld-cal mailing list<br class="gmail_msg"><br><a href="mailto:Halld-cal@jlab.org" class="gmail_msg" target="_blank">Halld-cal@jlab.org</a><br class="gmail_msg"><br><a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__mailman.jlab.org_mailman_listinfo_halld-2Dcal&d=CwICAg&c=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=y4ZD58I4nPR6tZqjerSGt-WlWVAhqa3FHDMXqQ_5aUc&m=yXEh1cAFzAHLirDbd8LBVxc84XcRZ9hACp_ytIMb8pE&s=-nNUG0o4KnJPZ4VmqWAQxVFapOeSoDqCZ0lUR9bNw98&e=" rel="noreferrer" class="gmail_msg" target="_blank">https://urldefense.proofpoint.com/v2/url?u=https-3A__mailman.jlab.org_mailman_listinfo_halld-2Dcal&d=CwICAg&c=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=y4ZD58I4nPR6tZqjerSGt-WlWVAhqa3FHDMXqQ_5aUc&m=yXEh1cAFzAHLirDbd8LBVxc84XcRZ9hACp_ytIMb8pE&s=-nNUG0o4KnJPZ4VmqWAQxVFapOeSoDqCZ0lUR9bNw98&e=</a><br class="gmail_msg"><br></blockquote></div></div></div>