Hi Gabriel,

2): yes, we need to use the monitoring application, in general, during 
ECAL commissioning with LEDs. The LED scan is not the first step of the 
process: I'll show a tentative proposal for ECAL LED commissioning 
Monday next week (and I'll forward the slides to the hps-software group).

0): the test I am referring to is not on the linearity of the system, 
since we do not know what the response function of the LED is (i.e., 
given an "input", the amount of light emitted), since the LED system is 
intrinsically not linear.
Rather, the test will provide the LED response function. Again, I'll 
discuss much better next week!

Andrea

Il 09/04/2014 01:50 PM, Gabriel CHARLES ha scritto:
> 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
>

########################################################################
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