[Brahms-dev-l] Re: Efficiency histogram...

From: Pawel Staszel <ufstasze@if.uj.edu.pl>
Date: Tue Feb 07 2006 - 07:59:00 EST
Hi Truls,

Good that you raised this issue.

Truls Martin Larsen wrote:

>Hi,
>
>have we decided on any official directory for the efficiency files yet?
>
>I have a suggestion if there is no official decision yet:
>
>make an efficDb directory in the directory where the official
>ltr/gtr/dst files are and put the root file there, eg CuCu 62.4GeV:
>
>ltr/gtr/dst files are in: /brahms/data21/data/run05/cucu/62/ (here they
>are pr run like: r[RUNNO])
>so for efficiency files related to these files could be:
>/brahms/data21/data/run05/cucu/62/efficDb
>
this is not too good because we could have
/brahms/data21/data/run05/cucu/62 and /brahms/data18/data/run05/cucu/62 e.g.
different runs,versions,productions for the same settings can be kept on 
different disks.
You don't want necessary redo efficiency maps because new production or 
version number.
Another ambiguity would come from the fact that efficiency maps depend 
both on ltrs files and on gtrs files (mainly the gtr offsets) and these 
are usually on different disks. 

>
>2. Alternative:
>
>make official efficDb for all efficiency calculations in:
>/brahms/data21/data/efficDb
>  
>
I like this solution.

>this 2. alternative could also be used for official acceptance maps:
>/brahms/data21/data/acceptanceMaps
>and for our corrections (from geant simulation of decay, mult. scat.
>etc...):
>/brahms/data21/data/corrections
>
We can also use the convention to reflect structure of banapp
/brahms/data21/data/corrections/efficDb
/brahms/data21/data/corrections/geanCorrDb (but this is just an idea)
What do you think?


Because we are close to use/create common efficiency files let me write 
a few words on that:
The the script used to produce maps 
(./banapp/correctios/efficiency/create_maps/MapEfficiency.C)
allows for monitoring the results without coping them to the db file (by 
default).
If the efficiencies look good the user can choose option to save results 
(histograms) in the
"db" file. If there are old maps they will not be over written but new 
histograms will be created
with incremented cycle number (number that comes after ";"). The 
EfficiencyCalculator will
always take the most recent cycle. (but it is possible to request a 
given cycle)

Maybe to control of what is going on in efficiency files
we should  associate cycle with some comments (person who did the map, 
date, any other comment).
The comment string can be added to a title of each histo.
How you see it?

>
>
>3. alternative is to add 3 extra data fields to the BrFileCatalogInfo,
>which would be the location of the eff. file, the accMap file and the
>geant corr. file for a specific run.
>
>
>Another question about the efficiency files:
>
>Many histograms have in their title a list of run numbers listed. Does
>this list mean that the efficiency is only valid for these runs? or all
>runs between lowest and highest run number? Or is it just a list of
>information to show which runs were used to do the calculation, and that
>they are useful for a longer range of runs?
>
This is list of runs which have been "merged" to calculate the maps and 
in principal
this list should contain all the useful runs for the analysis.
When you calculate the maps you see performance of each detector run by 
run and this gives
the possibility to make a final selection of runs. In other words you 
control whether everything is
stable in terms of local tracking.  If any detector in any run looks 
outstanding (e.g. efficiency is very low)
then you can decide whether you want to use this run or not. Note that 
performance in local tracking
is very hardware related (problem with HV gas mixture, wires). (I know 
that people use also other criteria
like number of global tracks per 1000 triggers).
Any way the list should contain all reasonably runs for given settings  
but it might be
exceptions (e.q. cucu runs with T1 problems which you have to use anyhow).
Because now analysis is more integrated one can easily check (running 
dst2tree)
whether the list of dst files added to the chain is consistent with the 
one used to calculate efficiency maps.

Cheers,
Pawel.

>
>Cheers,
>	Truls
>  
>

-- 
 ----------------------------------------------------------------------
| Pawel Staszel                                                        |
| Jagiellonian University                                              |
| Institute of Physics            email:      ufstasze@if.uj.edu.pl    |
| Reymonta 4                      phone:      (+48) 12 663 5712        |
| Krakow 30059                    FAX:        (+48) 12 633 7086        |
| Poland                                                               |
 ----------------------------------------------------------------------



_______________________________________________
Brahms-dev-l mailing list
Brahms-dev-l@lists.bnl.gov
http://lists.bnl.gov/mailman/listinfo/brahms-dev-l
Received on Tue Feb 7 17:25:21 2006

This archive was generated by hypermail 2.1.8 : Tue Feb 07 2006 - 17:25:54 EST