80 likes | 319 Views
Monitoring Shift 2008 – I3 Mainz Group. IceCube Collaboration Meeting 09/16/2008 Utrecht, Netherlands. Idea for Improvement #1: Automatical Alerts. http://i3moni.icecube.wisc.edu/cgibin/2008/run.pl?day=01&month=08&run=111395. Example: Run 111395 (shift taken by Florian) .).
E N D
MonitoringShift 2008 – I3 Mainz Group IceCube Collaboration Meeting 09/16/2008 Utrecht, Netherlands
Idea for Improvement #1: Automatical Alerts http://i3moni.icecube.wisc.edu/cgibin/2008/run.pl?day=01&month=08&run=111395 Example: Run 111395 (shift taken by Florian).) ● 22 DOMs automatically marked by the potential problems flag ➢ 14 ATWD alerts (''no ATWD'') ➢ 2 SN RMS alerts (''increased rms'') ➢ 1 Tcal RMS alert All these alerts are long-scale problems (present in previous runs!)) ➢ 5 ''new'' alerts (DOMs 63-39 to 63-43, different issues) ➔ Idea: make use of the long-term monitoring to classify DOMs ● Same problem occurring in several subsequent runs: set known problem flag ● New problem: report an alert on the web page
Idea for Improvement #2: Trigger References Example: Run 111396 (shift taken by Florian).) ● AMANDA_TWR_DAQ_STRING: reported deviation to reference run (Run 111395) of 13.1 σ ➢ Rate in Run 111395: 211.10 ± 0.10 Hz ➢ Rate in Run 111396: 212.81 ± 0.09 Hz ➔ First have a look at time evolution of trigger rates...
Idea for Improvement #2: Trigger References Example: Run 111396 (shift taken by Florian).) ➔ First have a look at time evolution of trigger rates... ● Trigger rate in bins of 10 min (current run and ref run)) ● Average trigger rate per run (in long-scale context)) ➔ Trigger rate in current and previous run shows a stable behaviour ➔ Trigger rate fluctuating in the range 202-218 Hz
Idea for Improvement #2: Trigger References Example: Run 111396 (shift taken by Florian).) ● To summarise: ➢ Rate in Run 111395: 211.10 ± 0.10 Hz ➢ Rate in Run 111396: 212.81 ± 0.09 Hz ➢ Between Run 111369-11140 rate fluctuating between 202-218 Hz ➔ Idea #1: think about error calculation ● Errors are too small compared to differences between average rates of subsequent runs ➔ Idea #2: think about a new reference method ● Get reference from long-scale observation / analyses
Idea for Improvement #3: Hit rate reference Example: Run 111403 & 111404 (shift taken by Thomas).) ● AMANDA-OM ''08-06'' (OM 200): alert (hit rate deviation) reported for Run 111404, not for Run 111403 ➔ Have a look at time evolution plots...
Idea for Improvement #3: Hit rate reference Example: Run 111403 & 111404 (shift taken by Thomas).) ● Fluctuations in Run 111402 (alert reported) and in Run 111403 (no alert) ● Smooth Run 111404: alert reported due to deviations from previous run ➔ Idea: Change reference method to avoid that ''fake'' problems are reported
Idea for Improvement #4: Visibility & Speed Example: all runs.) ➔ some minor but annoying problems ● AMANDA Channel Multiplicity: Fair amount of the plot is hidden behind the legend ● Java applets e.g Dom map needs very long to get loaded ● The Colors of the maps are not always favorable for the needs ➔ compared to last years monitoring shift, the monitoring was faster and improvement could be seen….