[Brahms-dev-l] Re: FS tracking efficiency with the reference method.

Hi Jens Ivar.

Jens Ivar Jordre wrote:

> Howdy Peter.
>
> Peter H.L. Christiansen wrote:
>
>> One things that I tried to do at some point was to check the 
>> extrapolated
>> yield of unidentified charged particles calculated with FFS and FS to 
>> the
>> published values. In principle this allows you to partly verify if the
>> combination of efficiency, decays corrections etc. is correct.... There
>> must be a power point from some colaboration meeting end of last year on
>> the BRAHMS homepage. I found that FFS was ok, but FS was generally too
>> low, but I think it was a premature conclusion in the sense that I 
>> should
>> use more time on this. I think it is a good idea to do make these 
>> kind of
>> checks, but probably you need a long time to really understand the
>> details. To sit down and really understand the FS is still a major task
>> for someone;)
>>
>> BTW it is also good to check that you have the latest greatest set of 
>> efficiencies from Pawel and remember that they are in principle 
>> related to a special set of reduced files with the tracking, geometry 
>> and magnetic fields as of that date.
>
>
> Pawel? Could you point me to your latest results, please? 

Concerning Run02 the efficiencies are stored in file Effic5361_5972.root 
(in ~ufstasze/effic) in 3D histograms.
The used variables were centrality, x and x-slope. I can see also file  
EfficDataInH3D.root which were done almost
one year later but for the same run range. I can't trace the whole 
history now by I think that
EfficDataInH3D.root was done for the newest production. Try to compare 
the creation date of your ltr files
and the  EfficDataInH3D.root (which is 4 Jul 2003). Note, that histogram 
title contains list of runs which were used
to calculate the efficiencies for a given field/angle settings. In 
EfficDataInH3D.root hist titles contain also
info about correspondence between histogram axes and physical variables 
(C-centrality, X - x detector position, Y - y
detector position, A - x track slope).  

Note, that I newer saw negative slope in efficiency versus momentum in 
Fs detectors (see e.g. http://www.nbi.dk/~staszel/fs/efficiency/index.html)

>
>
>> The bottomline is ofcourse that it is hard to say something _quick_ 
>> about the correctness of the efficiencies....... If however you want 
>> to trace the values of 100% you could start by studying the 
>> projection of the 3d efficiencies and I believe there is also a 3D 
>> count histogram. That way you might be able to identify the problems 
>> in a reasonably fast way. For me it is clear that with Pawels method 
>> you will have efficiencies that will be 0 and 1 because of the 
>> counting statistics and maybe also because of geometry/fields. This 
>> leads to the MC efficiency estimates ala Truls which is a tough way 
>> to go......
>
>
> I also assume efficiency of 0 and 1 are possible outcomes. In fact, 
> plotting the count from the 3D count histogram (i.e. the ones whose 
> names end with "_ref") resulting in efficiency = 1 shows smaller 
> number of counts relative to the ones leading to efficiency != 1. See 
> the attached plot. It looks like efficiency of 1 typically corresponds 
> to low count, which I suppose one may expect. Thus certain bins may 
> correctly have efficiency = 1.

Your conclusion is absolutely right!

>
> But it could also be that the low count is deemed insufficient for 
> determining efficiency and therefore it may be set to a default value 
> of 1 and filled in the histogram. Especially the fact that this bin in 
> the distribution is populated discontinuously from the lower values I 
> find worrisome. It appears to me that the default value for the 
> efficiency is 1. Is this true, Pawel? Is the code used for generating 
> the 3D reference track efficiency histograms located in some 
> brahms_app directory? There is some stuff in ps_app, but to which 
> iteration of efficiency correction calculation does the current 
> content correspond?

Histograms with "_ref" correspond to the number of reference tracks in a 
given bin. This your choice to set the minimum
number of the reference tracks to pick up the efficiency. If the minimum 
value is greater that 0 (which always should be)
you never pickup the default value (which I believe is 0). If in  the 
given bin you have less than required number of reference
tracks the method will search for the closest bin (Float_t radius = 
TMath::Sqrt((Float_t)((iY - yBin) * (iY - yBin) + (iZ - zBin) * (iZ - 
zBin))); ) which fulfill the requirements. I think that that's the best 
what one can do assuming that the efficiency
changes continuously and rather slowly versus x and x-slope.

This is to deal with the problem of statistics, however there is a more 
serious problem: to determine the T1/T2(FFS)
efficiency we use bfs tracks as the reference but bfs do not cover tha 
full acceptance of ffs, so the are x, x-slope areas
on T1 and T2 where this method can not be used. This is not a problem as 
long as we use full fs tracks as we
limit the problem to the bfs acceptance.

The stuff is in ps_app/fs/receff.
Let me make sure the cvs copy is up-to-date. I need also to extend the 
README file.

In two words: I produce tree with the reference tracks for each detector 
using BrEfficiencyFinderModule and
different scripts depending on the running period. Then there is a macro 
to read the trees and create/write
3D histograms. Using the macro you can monitor the efficiencies and 
select the variables for which you would like
to keep the dependencies, change binning, specify the sig

ma range for matching. (will describe all in the README)

Cheers
Pawel.

>
> Best wishes from
> Jens Ivar
>
>
> ------------------------------------------------------------------------
>





_______________________________________________
Brahms-dev-l mailing list
Brahms-dev-l@lists.bnl.gov
http://lists.bnl.gov/mailman/listinfo/brahms-dev-l