From: Flemming Videbaek (videbaek@sgs1.hirg.bnl.gov)
Date: Tue Nov 19 2002 - 22:00:06 EST
Dear Brahms-dev I think I will like to repeat + expand on some of the comments that I send to Claus a few days ago and which he incorporated in the most recent note, mainly because not all have seen this. A general comment is that for this to be truely utilized more commonly as is, rather than people appliing individual changes, there has to be a general way of settings options since not all analysis will be the same anyhow)(as also promoted from Norway). Some general comments a) one should be able to use the same analysis classes for pp as for AuAu - this implies different rejection based on BB and or Inel counters. b) There are places in the code where specific trigger requirements are chekced and code breaks. The trigger handling is not good - one cannot do analysis based on only a single value. The reason it worked in what has done so far is that the trigger 6 HAPPENED and not by design to be the highest number in centrality degree. One must operate on bit-masks. > The preloop should make sure it only attempts to determine constants (offsets) in region of momenat where these makes sense. One should not try to get a MassSq for protons where p>=8 GeV in FS and at lower value in FFS. And it seems to me much of this is in fact done better using 1/beta-1/beta(calc) for specific species. I am also concerned that it is in fact necessary to change offsets; this does imply that something in the basic calibrations is not right (t0's , momentum scale,..). > PidDefinition: Definition of the pid cuts, based on the histograms made in > the preloop. As you also allude to these cuts definitions should be made differently. A specific comment (also added into code) is that the TOF cuts are even in principle wrong as is. In any system there are two components namely dp/p and dt, but dp/p is nver a constant- usually it can be written as dp/p = (a/p+b*p) where the first terms is multiple scattering and the second from tracking chanber resolution. The main effect is at the lower p, and not so much at the higher. > Loop: Loop over the entries. Call the pid methods and fill the > ntuples for the further analysis. This is also an issue that > we maybe should discuss. Is this clever to fill the data into > ntuples for further analysis, or? I find the output Ntuple usefull for looking at specific, but do not really like creating them for the cross section analysis - the main reason being that it creates one more step in the overall analysis with output files. For each step it is at present with our lack of documentation/information storage nearly impossible to see how such step was done. Thus clarity is improved, but of course not ease of doing the final selection in different way's. So I am unsure what we should do. > PidMethods: Does the actual pid (from the measured quantities). We can > discuss if we want simple cuts for each detector (as it is > now) or if we want to introduce a more sophisticated pid > selection build on probabilities? See partly above - and yes I strongly agree that one should work in proper likelyhood values which implies working with 1/b-1/b(calc) /reselution <R>-<Rcalc>/(resolution) etc. One can eitehr work in masssq or time; time is overall better since the resolution is a slowly changing fct of p while in massq it changes rapidly (of course it is really the same if one does the functionaly forms/cuts correctly) For any system where more than one pid method is utilized the likelyhood is the proper method, but the backgrounf evalution is not quite as obvious. In fact there are corection in the presnet scheme that can only be done once you know the yield of other particles in a given y-pt/mt bin i.e. it is not just a effeciency depending on a particle. I am glad we are disucssing this looking forward to more input. Flemming ------------------------------------------------------ Flemming Videbaek Physics Department Brookhaven National Laboratory tlf: 631-344-4106 fax 631-344-1334 e-mail: videbaek@bnl.gov
This archive was generated by hypermail 2.1.5 : Tue Nov 19 2002 - 21:59:54 EST