 |
 |
Dear all, I am starting to write the software that we need during the ECal commissioning with the LED system (I'll open a Jira item soon, after this first round of e-mail exchange :) ). However, before writing any line of code, I think it is good to discuss with you what is the best strategy to proceed (sorry I probably can't attend today's software meeting). The task that I need to accomplish is the following. 0) Take data with the ECAL in the following mode: - For a given ECal channel, turn ON the corresponding LED with a certain amplitude, take 30s of data, turn it off for 10s, turn it on again with a new amplitude, turn it off,... - The LED system automatically provides this feature (SCAN). For each channel, 3 numbers are defined, ampl_low, delta, Nsteps, so that the scan is performed with Nsteps LED amplitudes, starting from ampl_low, with delta increment. ampl_low, delta, Nsteps will be saved in the database (TBD). - The trigger is provided by the LED system itself. This will result in a data file with the following structure (for the LED being pulsed): * Data for the first LED amplitude * A series of "~0" (not necessary there if we have a threshold on the amplitude) * Data for the second LED amplitude * .... 1) Analyze this file to get the LED response curve, i.e. the measured amplitude from (crystal+APD+amplifier+FADC)system VS the LED set amplitude. This will require to run the reconstruction to produce the EcalReadoutHits collection (raw energies). Later, when calibration constants will be available, the same procedure can run on the EcalCalHits collection. Preliminary question: actually, the EcalReadoutHits are produced by the EcalEvioReader class being "called" from the TestRunEvioToLcio main class (to read EVIO). Is this going to be the same also in the production run? Will we use the same main class or will be there a "HpsRunEvioToLcio" equivalent for the production run? Main question: what is the best "strategy" to analyze this file? i.e., I see two main options: a) Stay within the hps-java sofware framework and do everything there Pro1a: everything is done in the same framework. Pro2a: can use code that is already in place. For example, I'll need to access the database to retrieve, for the channel being analyzed, the 3 numbers: ampl_low, delta, Nsteps. This is easy to done with the condition system that is already in place. b) Use hps-java software to produce an lcio file with the EcalReadoutHits (or the EcalCalHits later). Then, run a ROOT macro on this file (using the LCIO Dictionary that I already tried and I am familiar with). The interaction with the database can be done in hps-java software, writing at the end of the lcio reconstruction a txt file with the relevant information (ampl_low, delta, Nsteps), and read it in ROOT, OR ROOT itself can interact with the database. Pro1b: I already have a similar code (for the CLAS12-FT project) to accomplish this task in ROOT, and it is easy to adapt it. Pro2b: I am more familiar with ROOT than with (any) equivalent JAVA analysis package (I need to perform fits with gaussians and polynomials and to use TH1, TGraphs, TH2). c) (not sure how feasible!) Use ROOT within hps-java. Personally, I would investigate if option c is feasible. If not, I'd proceed with option b because of Pro1b. However, I'd like to share this questions with you before proceeding Bests Andrea ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the HPS-SOFTWARE list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1