Hello all, Sorry for the delay in commenting on this. The following are replies to Ian's comments below. 1. Histograms are currently saved by a simple fReferenceMonitor->Write(). So Ian would be correct in saying that the most straightforward way in getting to the spectra is with the monitor. Flemming showed a script to get at spectra, because once you open a root file, you have access to things. I plan to do something so that you can get to the spectra more straightforwardly, but have not decided on an interface yet. 2. A fitting procedure somewhat more adapted to the monitor is both feasible and not hard. All it would do is interface into the root stuff which as you noted is already there, but requires a bit of navigation to get to. 3. I have been thinking of scatterplots on the fly. The scatterplot object I made seems to work and I debugged it further with some stuff we do here at tamu and that will be folded back into the monitor. (See, brahms and nimrod feed off each other) For making them on the fly, given some things I did with root here, I now know some of the basics of making it so that you can do that. The problem again is with the interface. That can be decided. In addition, I think it needs to be general and the TOF guys have BrDigTof's which are elements of a table (I think they still are) and the ZDC guys have BrDigZDC's which have all the info in them. As said above, I now know how to access them given the name only, but am rather fuzzy on how to overcome making it general while getting users to have to do as little programming as possible. As far as defining histograms on the fly, I had not thought of that, but once the above problems for scatter plots are solved, these should fall out. 4. I am very concerned about the short lifetime before hanging up. I have done some tests here and it hung up once, so I put some print statements around the two event by event statements where BrRawDataInput interacts with the event builder. Then it ran either all day or all night without hanging up. That might point to a timing problem since putting those print statements slows things down. On the other hand, I am able here at TAMU to read 2 events per second, so if it is a handshaking problem, it is much less severe and perhaps I got unlucky when it did hang. I plan to investigate this intensely when I am at BNL in a couple of weeks because as far as I am concerned it is a "show stopper" and I see no reason to believe it is a root problem. But I don't see what I am doing wrong either. Regards Kris Ian Bearden wrote: > 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 : Thu Apr 13 2000 - 20:37:00 EDT