On Fri, 2006-01-13 at 12:32 +0100, Pawel Staszel wrote: > Dear Truls, > > Truls Martin Larsen wrote: > > hi, > > > > I also agree. But I have a suggestion to the logistics: > > > > lets make a directory in banapp called "corrections". > > > > This directory can then be the place holder for the > > EfficiencyCalculator, the AcceptanceMap classes and when Catalin > > finishes his feeddown, etc study, a class that can give this correction > > number for a given particle. > > > > This will then be compiled into a library called libCorrections which > > then also can be loaded by the "anarchistic" people ;-) who does not > > want to/can not use the rest of banapp package. > > > > What do you say? > I like your idea to keep all corrections in one subdir but on the > other hand efficiency correction is > added when going for dsts to trees which is not the case for other > corrections (I believe). So the disadvantage of such > solution would be that changes in e.g. EfficiencyCalculator could > affect the part used for other correction derived from > geant simulation . (efficiencies based on analysis of ltrs and > dsts). > Let us wait for comments from US, and then we make the final decision. Adding the efficiency corrections to the tree is no longer part of the micro tree generation code, as I felt it was mixing up this to much, the only thing one to change was to replace "particle.fEff" with EfficiencyCalcuator::[Fs,Ffs]Efficiency(momentum, etc...) And you also avoid having to have the efficiency maps in hand when making the micro trees. So if one uses the current version of banapp it should not be a problem... I'm not sure if it should be a problem otherwise either, but... lets hear from the people with their hands in the dirt... > > Another question for you Pawel, have you looked at the efficiency vs the > > occupancy (if there is some kind of variable in the DCs which is if such > > naure)? In the TPCs the occupancy is the number of hits in a TPC in an > > event. This I think, would give a better description of the efficiency, > > since a peripheral event well could send a shower of particles towards > > the spectrometer. And since we use track triggers, isn't that what we > > "always" try to get stored!?! > > > > If you have some histos with this laying around, it would be cool to see > > it! if not, would it be a big job for you check it out/make it? > > > I can add a new entry in the track reference branch if you think that > it might be useful. > The idea to use only the centrality is that it is common parameter for > all detectors and > that the final physics results are sorted according to centrality. The > disadvantage is that it does not fill > the local particle fluxed in the vicinity of a particular detector, > but still these fluctuation > are not important (they just become averaged) if the data are > presented versus centrality classes. > > But as I said it is not a problem to add a new entry to store the > total number of "good" hits. With good hits do you mean only hits belong to a track or do you mean the total number of reconstructed hits in the detector? The total number of hits in the detector is only quasi related to the centrality of the collision because of the track triggers, unless one suspect the "background" hits (ie hits not belonging to a track) to scale with the centrality, or be constant... The way it affects the efficiency in the TPC's can be seen on page 81 and 87 in my master thesis: http://www.nbi.dk/~trulsml/master/brahms_tpc_eff.pdf.gz In the MRS it has the effect that a high occupancy event might have a correction of 0.85 about but a very central event 0.9 . Though the Fs does not show such a strong dependence/deviance... Its probably fine to keep the centrality as the parameter to use, I was just curious :-) cheers, Truls > > > Cheers, > Pawel. > > > About the DST branches: > > > > what should be removed: > > G.fNoFfsTracks (this is stored in FFS_ branch) > > G.fNoBfsTracks (this is not used and for FS its stored in FS_ branch) > > G.fRunNumber (this is stored in R.fRunNumber) > > > > what could be removed: > > R.fNTriggerX (where X is 1-8, what does one need this for? it is also a > > potentially dangerous variable as it does not have to be the number of > > triggers in the run (explained in an earlier email)) > > > > what should be added: > > G.fNoMrsHits (needed for efficiency in MRS: nTpm1Hits+nTpm2Hits) > > G.fNoFsHits (needed for efficiency in FFS: nT1Hits+nT2Hits) > > > > (Putting in the tpc rdos in the tree is absolutely overkill...) > > > > Cheers, > > Truls > > > > On Thu, 2006-01-12 at 07:51 -0500, Flemming Videbaek wrote: > > > > > Dear Pawel, > > > > > > I agree and think I alluded to this in one of the pnoneconference in the fall. I think you should take responsibility, > > > since what most peopl uses (at leat RD myself and you) is derived from your package and not the version in banapp. > > > Why not make the effeciency stuff a 'subdir' in the banapp package ? > > > > > > Flemming > > > > > > -------------------------------------------- > > > Flemming Videbaek > > > Physics Department > > > Bldg 510-D > > > Brookhaven National Laboratory > > > Upton, NY11973 > > > > > > phone: 631-344-4106 > > > fax: 631-344-1334 > > > e-mail: videbaek @ bnl.gov > > > ----- Original Message ----- > > > From: "Pawel Staszel" <ufstasze@if.uj.edu.pl> > > > To: "Truls Martin Larsen" <trulsml@nbi.dk> > > > Cc: "Brahms Devel List" <brahms-dev-l@lists.bnl.gov> > > > Sent: Thursday, January 12, 2006 5:57 AM > > > Subject: Re: [Brahms-dev-l] banapp 0.7.0 > > > > > > > > > > > > > Dear Truls and Flemming, > > > > I checkout new version of banapp and found out that the > > > > EfficiencyCalculator which it there > > > > looks as a toy class and ignores all the results I stored in analysis > > > > notes on fs efficiency > > > > see: > > > > http://zefir.if.uj.edu.pl/staszel/brahms/fseffic/yieldscorr/index.html and > > > > http://zefir.if.uj.edu.pl/staszel/brahms/fseffic/yieldscorr_update/index.html. > > > > > > > > Right now EfficiencyCalculator has double functionality: it serves as an > > > > interface for > > > > detector efficiency maps as well as it calculates the efficiencies for > > > > global tracks (Ffs and Fs). > > > > These two are properly supported by the bnapp version. > > > > > > > > I can take the responsibility to keep EfficiencyCalculator up to date > > > > but there are few EfficiencyCalculators > > > > used by different people. We should agree to have only one official > > > > EfficiencyCalculator, and it might be the one which is > > > > in the bnapp. The other solution is to move Efficiency Package from > > > > ps_app/fs/receffnew in to brat and make EfficiencyCalculator > > > > as a part of it. > > > > > > > > Please comment, if we agree on something then I can come with the updates, > > > > > > > > Regards, > > > > Pawel. > > > > > > > > > > > > Truls Martin Larsen wrote: > > > > > > > > > > > > > Hi, > > > > > > > > > > for those of you interested, the banapp code has been updated to read > > > > > the new tree structure in the dsts. Also some other small changes and > > > > > fixes where made. Code was added to the cherenkov selector (CSelector). > > > > > > > > > > New version is 0.7.0, tagged banapp_0-7-0 > > > > > > > > > > BTW, > > > > > if I haven't said it before, the official code is in: > > > > > > > > > > BRAHMS_CVS/banapp > > > > > > > > > > Cheers, > > > > > Truls > > > > > > > > > > _______________________________________________ > > > > > Brahms-dev-l mailing list > > > > > Brahms-dev-l@lists.bnl.gov > > > > > http://lists.bnl.gov/mailman/listinfo/brahms-dev-l > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > ---------------------------------------------------------------------- > > > > | 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 > > > > > > > > > > > > > > > > -- > ---------------------------------------------------------------------- > | 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 Fri Jan 13 11:41:11 2006
This archive was generated by hypermail 2.1.8 : Fri Jan 13 2006 - 11:41:23 EST