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
|