80 likes | 190 Views
2009 Online monitoring experience & some C-AD activities/preparation for the roman pots in the coming run July 23, 2014 Kin Yip Collider-Accelerator Department. 2009 Online Monitoring Experiences. First stage of online monitoring is probably more like debugging (after DAQ worked): Experts
E N D
2009 Online monitoring experience & some C-AD activities/preparation for the roman pots in the coming run July 23, 2014 Kin Yip Collider-Accelerator Department
2009 Online Monitoring Experiences First stage of online monitoring is probably more like debugging (after DAQ worked): Experts Team member A Team member B This necessary step has made the experiment possible and we/I have learnt the necessary ingredients to write the online/offline codes including making our DST. STAR Online Monitoring histograms/plots Used to be “online/RTS/scr/OnlinePlots/HistogramGroups/pp2ppHistogramGroup.h & cxx” ; now, moved to “OnlTools/Jevp/StJevpBuilders/ppBuilder.h & cxx” ( I’ve tried recently, it works ). Quick analysis (without calibration) Codes kept in the STAR CVS repository of mine: “offline/pp2pp/kinyip”
For all these, one is dealing with the raw data. STAR standard online plots seem(ed) to have sampled too few (not enough anyway!) events and haven’t seemed to betoo useful (rather than just telling us whether we had taken data or not). There are some restrictions (can’t be too many bins etc.). Jeff said: “The plots shouldn't take very long to produce. Each builder handles events separately and is given the same amount of clock time. If you start using more than your share of processing time, then you get fewer events sent to your builder.” Nevertheless, we can/should explore to improve … For the “quick analysis”, you can do as many things as you have time/resources to. You may even read the current files during a run (from “/a” directory in the node “evp” as Jeff taught me in 2009), in addition to the data files on tape. In 2009, I wrote a quick analysis program that some shifters have run to look at the data, either files on tape or in “/a” (we’ve had a NFS link in blanchett(2) ). It was a simple command line program and we can make it more elegant … We’ve also taken pedestal data for all channels for each store (at least). One’d notice if DAQ/electronics had any problem.
Quick analysis Online plots
We’ve asked the Control Group (in C-AD, Seth Nemesure), to create an application to automatize the roman pot insertion. There was already an application called “RomanPot” in 2009 but we still used the Pet page to insert. The motor step (vs cm) calibration needs to be checked/repeated when/after the alignment group does the alignment. Vincent Castillo (C-AD) has checked out/recalibrated the 3 out of 4 NMC’s (integrating radiation monitor device) and have been operated in the RHIC tunnel during the 2014 RHIC run. David Gassner has moved the roman pot (outside RHIC but circuit connected with the NMC inside RHIC) in and out to see whether there was any anomalous NMC readings (none). Vincent said that he’d found quite a couple problems with the NMC’s that were handed over to him (somehow he didn’t handle the NMC’s in 2009) and he’s calibrated them. ( He thinks he might have corrected problems that we experienced in 2009. )
The threshold has been set at 100 Rad/hour. In the 2014, from “LogView”, we saw spikes at the beginning of each store, which should be the time when we did rebucketing. We certainly have to turn off the NMC beam-pulling logics during this period. mRad/hour