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