Summary of BLAST analysis meeting 8-7-02 we discussed a long agenda mostly coming from last week, summarized the status of data-taking and of data analysis. ====== General ====== _ This meeting is the replacement of the weekly blast meeting and of friday's software sessions. All students are invited to come. Tancredi will coordinate the online analysis effort as well as day-to-day software management. Your contribution will be essential for a good BLAST run and quick data collection and analysis !! _ The meeting will occur weekly at Bates at 2 pm. You were all used to the wednsday meeting anyways. If you have suggestions on the schedule please let me know. The hope is that 2 pm will give us a better chance to overlap the people on day & evening shifts. If many of you can only come with the shuttle that may be arranged as well or the time changed. _ Also, I assume there are no major complaints about how the software/analysis is structured right now (please do complain since you are using it). _ I plan to have you make a brief presentation of the status of your project, when nearing completion. Nothing formal. Slides are also not strictly necessary. We have a whiteboard in the conference room. _ The last general thing: we want to make progress on a number of projects but ultimately we are focussed on analyzing physics data. The situation is fluid as we will have data from various configurations to analyze during the whole commissioning run. For instance, we will stop ep data taking for a while when the wire target is in. I want to stress that - under smooth production running - when *you* will be on shift you will be expected to do *shift work*, which includes data analysis. This is the best way to help. You'll have to work on your projects at another time or if there is no beam. This experiment will not walk by itself and actually on shift you will learn the most. Analyzing yesterday's data is also in everybody's interest. So, here is the big list, in some order. Please join us at the meetings and pick any. ===== Physics Analysis ======== If you do not have any (or never had) a software project you should probably start here! + Cerenkov Efficiency Need to analyze recent and old runs. We still need a macro + LO - Delta_E Calibration of the light output in energy deposit is possible in a relatively quick way (quicker than geant anyways independent from the simulation). + Chamber Cut _ Even after background optimization, we need to select events coming only from the target region. A final Wch anaylsis is a long way to come and we can profit from having at least primitive tracking information before that. What I mean is to use cell information, geometry, to arrive at a very first selection. The goal is to be able to say which event came from the target "region". The chambers still need to take first data, and their basic operation and output understood. The chamber group will take care of this project. + Montecarlo, X-section _ I expect you are all very familiar with BlastGeant. I may not, but I am familiar with Geant and Montecarlo. That's enough. It may be important to go through the steps required to extract a cross section, what a simulation can do, how it should be used. I would be very willing to help and discuss with whom is interested. I am of course waiting to get more familiar with each others experience and work. + TDC (calibration) _ We know each TDC channel has its own pedestal value or offset. This has been quite misleading in the first weeks of running. This information is in principle available (and/or can be recollected) but it should enter the data analysis. Action: P. Karpius _ TDC calibration: closely related to the above. Even if we correct for the offsets, we have to believe that the calibration is 20 channels/1ns. That's what the manual says. Given the above, we should check. It maybe slightly different in each channel (e.g. 20.01, 19.76,...) Action: none. There is a dedicated FastBus module for this which will obviously require control. So this is a good FB chance.. + Gain matching _ TOF scintillators were carefully gain matched in the HB area. However, we had to adjust some voltages by hand, change some tubes. At the moment there is no urgency, but we have to revisit this one. I hear there is a specialized software to do this, pass it on or else let's try to fix it. _ Related to the C efficiency, we have to find optimal operating voltages for the Cerenkov. After the wire target studies, we'll have to do the same for the neutron bars. _ Genya showed some analysis (thanks genya) and quick way to check the gain matching + Retiming _ Recent runs should be analyzed to find consistency with the retiming settings of two weeks ago. + Cuts _ The idea is to have a general, central repository of cuts. These will be defined in commonly shared files, and parsed during your root session. For the user, a new class will be available that will allow to make cuts transparently and unambiguosly. The idea is to minimize any subjectivity or user to user inconsistency on what is a good "proton cut", e.g. This is a strong effort to centralize our definition and harmonize users' analysis. Also, at some point logical names can be used which will make any code much more readable and functional also for less-expert or beginning root and blast users. Action: Chi has started looking into that with some early results. More technichal details next week. + FourVectors _ Once the real physics analysis is underway we will definitely consider importing this nice library (presently in the Cola package and the D2 generator). ===== Hardware ======== + Beam gate _ We need to set a hardware beam gate, that inhibts data taking when a we have a HV trip. This is typically done using logic levels, NIM electronics. Possible connect the trip to a gong (audible alarm) in the counting bay. Tb doing necessary changes. Sinh will program the crates to obtain the HV trip condition clamped to ground on bnc out. ===== Software Projects ======== + HV controls: quite some activity here. Will be discussed in more detail at a specific time (let me know if you want to be involved, thanks). _ logging of HV: can do by archiving a simple text file, with an "HV event" at the beginning of the run, eventually in EPICS. The first can be done (almost) today. For the latter, we need an EPICS driver for our hardware or define an EPICS virtual (or soft) channel. _ HV gui: nice, not heard report but we know there is activity here _ HV "ramping done" status bit: this ties with the discussion of automated run control. We wish to set a flag for when the HV has been ramped up (not just "HV is ramping). Sinh is looking into the code for this. _ After the above "ramping done" status bit is extracted from the crates, we need an epics interface (soft channel) to ccr. Eventually our HV status will interlock CCR operations. Also lab people can help. _ *Note* Although we can interlock to an HV trip, it does not seem easy to (rapidly or synchronously) interlock a beam gate to the ramping status We discussed the necessity to create a special coda event in the stream. Likewise, we will need a "clean" target-spin-bit-has-been-set event. Discussion under way. + Archiving/Logging of configuration files _ This discussion was originally related to "how to save/archive the trigger settings". Now we want to save e-.map, epics.map, scaler.map (!) Could also be a solution for HV (see above). _ Action: thanks to CC we have a roadmap: a general class will allow one to "submit" (at least initially *manually*, via command line or gui) any change in one of the above configuration files to a mySQL db (in form of a time-stamped file-name) and an archive (where the file can later be retrieved from). This project is almost in its final stage. + Scalers _ Discussed some modification (more channels). With just the scalers stream we should be able to monitor normalized rates, beam quality monitors (f.i. a scaler counting 3&13 elastic coincs) and also dead-time (which could be an issue for very open triggers) _ Action: none. What is required is a simple screen for monitoring other scalers than the raw pmt counts. We basically need to modify existing code (one modification is to do basic arithmetics between two channels). Stripcharting is a (non essential) optional _ Making a snapshot or cutting and pasting with the mouse strangely formatted text is *not* convenient. Please help dump scalers into a (printable) file ! _ Action: none + Online/Realtime event display: _ Used to work, simply not there anymore. However we are rather flat out to make this a high priority right now. Coda data can be analyzed practically online. We discussed how we should find/solve more problems (for which task we have all the tools), before working on alternative or additional software.