 |
 |
Hi Andrea, I think your steps are the ones that should be performed. Just a few remarks and questions. 0) How many different amplitudes do you want to take? I think 2 is a minimum to check the proportionality between input signal * gain and the output signal. The second one could be for example, twice the first. The first one being a signal leading to an output of 0.9 V, such that we are close to the saturation at the second amplitude, what do you think? Do you see a reason to use three different amplitudes? Maybe another one at low amplitude? 1) I would go for 1)b, also to test the code. 2) More general question: will we be able to test the monitoring application during the LED scan? Le 2014-09-04 11:44, Andrea Celentano a écrit : > 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 -- Gabriel CHARLES Institut de Physique Nucléaire d'Orsay ######################################################################## 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