This has been a busy day with not so much time for digesting these messages. It seems though we have reach some concencus. The effecincy and otehr belong in a seperate directory & library since they are applied at the end of analysis and in different ways depending on if one is analyzing the bdst od microtrees. I am a litle puzzled why you keep the nT1Track+nT2Tracks. (or hits) Why not have these as individual varaibales for over consistency. E.g in MRS I double that the #track in tpm1 has a strong correlation with the #tpm2 tracks. On the decay/abs correction I have not quite complted this for 2.3 amd 4 deg. I will try to get it done over the next two-three days. I have in fact learned something quite interesting; The cuts that are effective to create 'clean' pions are quite different in FFS and FS. For FS the chisq**2 do get rid of 'decay' pions, bad multiple scattering- in FFS this does not help at all.A mult scattering between T1,T2 basically will give you a 'bad' momentum but still a good chisq. On the other hand the 'target projection cuts is very important and do through out a large number of bad tracks. The vtxY,vtxX cut is MOMENTUM dependent. so even if the regular method of fitting the variables and determining takes paretly care of this there are residual cuts made that could change effeciencies. This has to be looked at with data, but in simulation it is a very clear effect. For FS the target cuts have a very small effects. flemming ----- Original Message ----- From: Pawel Staszel To: Truls Martin Larsen Cc: Flemming Videbaek ; Brahms Devel List Sent: Friday, January 13, 2006 6:32 AM Subject: Re: [Brahms-dev-l] banapp 0.7.0 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. 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. 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 19:07:27 2006
This archive was generated by hypermail 2.1.8 : Fri Jan 13 2006 - 19:07:40 EST