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
|