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? 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? 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 > > > _______________________________________________ Brahms-dev-l mailing list Brahms-dev-l@lists.bnl.gov http://lists.bnl.gov/mailman/listinfo/brahms-dev-lReceived on Fri Jan 13 05:27:37 2006
This archive was generated by hypermail 2.1.8 : Fri Jan 13 2006 - 05:27:44 EST