> Hi Bjrn, Trine and Truls
Hi again :-) How are things in Denmark?
> First of all, a very nice and detailed note. Great to read. I have a few
> questions :
>
> * What kind of cuts were apllied on the tracks except the acceptance
> cuts.
> X and Y vertex cuts, chi**2, etc.
Easy: None. Currently all other background-correction etc. is done via the
double-gaussian fit. I know this is not optimal and I'll introduce some
more cuts in the next round. Planned: better background from GEANT,
dist-from-vertex cuts, cuts on the track residual (Trine has shown that
this might be useful). But as I say - next round.
> * What tracking parameters were used.
The ones that Flemming used for his QM analysis:
t1_localtrack->SetDebugLevel(0);
t1_localtrack->GetClusterFinder()->SetLowCutPsig(0.6);
t1_localtrack->GetClusterFinder()->SetHighCutPsig(1.5);
t1_localtrack->GetClusterFinder()->SetLowCutTsig(0.6);
t1_localtrack->GetClusterFinder()->SetHighCutTsig(2.2);
tracker = (BrTrackFollowFinder*)t1_localtrack->GetTrackFinder();
tracker->SetSearchWidthX(0.60);
tracker->SetSearchWidthY(0.0);
tracker->SetHitSearchWidthX(0.3);
tracker->SetHitSearchWidthY(0.6);
tracker->SetTrackingMethod(1);
tracker->SetLocalTrackLimit(1000);
Plus some dead-pad settings, but not for TPM1...
> * How long time does it take to change something and redo the analysis
> (just curious)
The entire analysis: ~17hrs for the reco, a few hours to make the
tracktrees etc and a few more to get the numbers. All in all, since I
usually make at least two mistakes, two days to have proper, checked
numbers.
I agree the above parameters should have been in the app - sorry.
> It would be great if the efficiency tester would be made public in
> brahms_app, I would like to test it on T1.
This is also planned, only we have to make "proper" versions of all our
changed code first. We'll try to get it out soon.
> The problem with a dip in number of tracks vs pads is related to
hot/cold
> pads. Plot number of clusters vs pads and rows (2d) and you will see hot
> regions and cold regions (gStyle->SetPalette(1) ;). If you remove those
> from the detectorparams file and you obtain the correction vs pads AND
> number of clusters you are safe, but maybe you can just extrapolatem, if
> you just have a dip - someone stronger in the force can probably guide
you
> better.
We suspected something like this - thanks. We'll have a look at it.
> It would be great if you instead of plotting number of crashes vs number
> of clusters plotted vs centrality class just to make sure. It seems that
> this is something that needs to be fixed. It is good that the
> trackstringfinder does not crash. I have some ideas for improvements but
> also other problems that I would like to solve, so it depends on what
> priority people thinks this should have.
I can check that pretty quickly - just need to find the time. Any
improvements in TFF would be great, but not pri#1 since I believe we now
correct for the problem pretty well. Still, if the crashes were to stop we
would not have to correct at all :-)
Hope this answers most of your questions?
Ping to you all :-)
------------------------------------------------
Bjorn H. Samset
Master-student in Heavy Ion physics
Mob: +47 92 05 19 98 Office: +47 22 85 77 62
Adr: Kri 2A709 Sognsveien 218 0864 Oslo
This archive was generated by hypermail 2b29 : Wed Feb 21 2001 - 10:57:41 EST