Dear all,
I have now used the monitoring software quite a bit, and would like to
share my experience. I would also like to encourage others to use this
software as it is
CRITICAL to the success of our upcoming run. The more we use it now,
the better chance we have of having software that works in the way we
want it to. In other words, we should not expect Kris to produce all of
our software (though, it seems as if he is trying to!).
The routine I am using was modified from some of Kris's code by Peter
Christiansen to read TOF data and produce some monitoring histograms. I
have made a few cosmetic changes to the histograms, but the bulk of the
real work was done by Kris and Peter.
As it now exists, the BrSuperMonitor can be used for some (perhaps most)
of our immediate monitoring needs. It is fairly straightforward to run
and the user interface is very good (for those who like pointing and
clicking). Thus, one can produce, save, and print various histograms in
an easy way, allowing one to monitor the performance of various
detectors.
As I see it, there are still some 'issues' to be worked out. The most
important is the stability of the program. My estimate is that the mean
time to failure of the program is something like 30-45 minutes. The
failure that I have seen is that the program gets hung and does not
respond to anything. To recover from this, I have killed the root
process (for you UNIX heads, I mean of course the program "root" and not
the processes on the machine run by the root user.) and then restarted
root. I guess (but it is only a guess) that something goes wrong in the
communication between root/brat/supermonitor and the event stream, but I
have not tested using only the random number input to see if failure
occurs there as well. This is the only real problem with the running of
the SuperMonitor that I have found.
I think that we need quite a bit more functionality to have an optimal
program.
Here is my "wish list," please let me know if these things are
unreasonable/impossible/undesirable. The order is the order in which I
remember things where I thought "gee, it would be cool to do...", the
list is not necessarily complete, and may include luxuries which can
wait until later.
* Histograms should be saved on a 'standard' root file so that after
a run, one would have quick access to such files without having
to use the SuperMonitor. Note: it is my understanding that the
only way to read "saved" files is through the Monitor itself,
please correct me if I am wrong.
* It should be possible to fit histograms. This may be possible
already, but I didn't figure out how to access the histos from the
command line, although it is possible (I just found out!) to fit
using the interactive properties of the root canvas.
* I would like to be able to make "pictures" on the fly. That is, I
can imagine that I'd like to look at, say, Slat 1 ADC top and Slat
1 ADC bottom at the same time. As I understand it, we now must
know a priori which groupings of histos we want. Again, this may
be possible, and I am just too thick to figure it out.
I would also like to encourage each of the people responsible for a
detector to try to come up with histograms, which can be clearly seen
and understood, that can tell the casual observer that all is (or is
not) well in one or two canvases. For TOF walls, such histos would
include hit patterns for top ADC, bot ADC, top TDC, bot TDC, top&bot
ADC, top&bot TDC. One glance at such a screen should show which, if
any, channels have problems. Such histos would NOT include 40
individual energy spectra, etc. these sorts of things should be saved
for detector specific monitoring. Also, we should test our monitoring
software out on such 'casual observers' to see if it makes as much sense
to them as we think that it should.
To sum up, I'd first like to thank Kris for all the work he has done to
get us to this point. I have claimed that there is rudimentary
monitoring software for TOF (H1, H2, TOFW) which has been run, but is
not yet optimal. I have also raised a couple of questions about
problems (primarily the short running time) with the BRAT monitoring
software, and made a couple of suggestions for functionality which I
believe would be rather useful.
Now I will try to practice what I have preached and try to optmize the
TOF monitor and make it public.
Best Regards,
Ian
This archive was generated by hypermail 2b29 : Wed Apr 12 2000 - 09:06:44 EDT