 |
 |
Hello Andrea, I would suggest to go with Option B. The only thing you do not have there is the access to DB to get your 3 variables, is not it. I am not sure why you need LCIO, why you cannot read raw info from EVIO. Since we will have several options for gain calibration and we will change gains over run time, I would prefer to monitor non-corrected (gain) response of APDs with LED system. The main purpose of the LED system is to monitor stability of ECal module response. As for LED info, we will have EPICS info in the data stream one way or other, so the LED pulse values, that I assume will be available in EPICS, can be injected into data stream. So, we really do not need DB to store them. These calibration runs/files should be self sufficient to make studies that we need. My two cents. Stepan On 9/4/14 5:44 AM, Andrea Celentano wrote: > 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 ######################################################################## 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