Hi Pawel, I faced time ago the problem you say with the long runlist for 2 degrees pp data. The problem is related to some limitations in CINT for the size of this type of arrays as we have in the MapEfficiency.C. It is going to run properly for all the runs if you compile with ACLIC the macro. By doing this and loading the shared library when running you gain also much faster execution. Of course, to compile it, you'll have to code properly the macro (like function declaration, type conversion, etc). But it does worth in the end. Kind regards, Catalin. On Friday 18 August 2006 18:21, Pawel Staszel wrote: > Hi, > > The instruction given in my previous mail is not quite complete. > Please refers to the README file (in banapp/corrections/efficiency) > for the more complete instruction of how to create and deal with > the efficiency maps. > > Best regads, > Pawel. > > Pawel Staszel wrote: > > Hi Flemming, > > > > flemming videbaek wrote: > >>Hi Pawel, > >> > >>Thanks for letting me know. This should not effect the spin > >> asymmetry analysis, since effeciencies > >>basically cancels out due to the measurements of alternateing > >> buynches with spin up/down. > >>Of course when statistics get low there could be an issue, albeit > >> small. > > > > OK, > > > >>As you > >>I would think that one has to store the effeciencies with some > >> marking of the run's for which it is valid > >>in addition to the actual setting. An overall average is of > >> course a problem due to the fact > >>that not all runs may be in a specific analysis. > > > > The list of runs used to produced particular maps is specified in > > the title of each histogram. It can be > > checked by editing the file containing maps in the root session. > > By default I try to > > use the complete list. > > However, if someone wants to have only maps for the limited set, > > then he/she has to make the > > maps by him/her self and specify the proper suffix which we > > agreed to be like "PSv1" (see files in official trackEff). > > The EfficiencyCalculator (which is in fact EfficiencyInterface) > > uses "PSv1" as a default but there is a SetSuffix > > method that allows for the other choices. (e.g. files produces by > > Natalia for run04 have suffix "nkv1" or "nkv2"). > > In the other word suffix can be used to specify a given set of > > merged runs. > > > > This is a short instruction of how to create maps for a specific > > set of runs ASSUMING that > > one runs on RCAS farm and that the files with trees are already > > there: > > > > The data (trees) needed for calculating the maps are store in the > > semi official place which is > > /brahms/data21/scratch/efficiency/ > > The method MapAll (from MapEfficiency.C which is part of banapp) > > knows this location by default. > > > > step 1. update your banapp/corrections/efficiency (using -A -P -d > > flags) > > > > step 2. go to efficiency/create_maps > > > > step 3. edit MapEfficiency.C > > > > step 4. go to GetRunArray method find the proper period, specie, > > energy, rotation/polarity/current setup and > > modifies List array according to what you need. Note, that you > > have to update the list of runs in two places: > > in the List array and in the string Title (the second is needed > > to propagate the runs list to the file containing > > the maps). > > > > step 5. run MapAll - the header of the macro contains > > explanations for the list of its formal variables, > > e.g. MapAll("run05_pp",200,2,861,"XAP",1,true,true,"PSv1","Maps > > created on 15.08.2006 by PS"), > > For this example the maps will be saved in the file > > ../efficdb/MappedEffic_run05_pp_200_PSv1.root. > > Remember to use your own suffix and provide a valuable comment!!! > > > > step 6. copy MappedEffic_run05_pp_200_PSv1.root (you should be > > bramreco) to the official destination which is > > /brahms/data08/corrections/trackEff to let other people enjoying > > your work and to have an access to the maps via > > EfficiencyCalculator with its default setup (you just need to > > specify the suffix). > > > >> Do you think one really has > >>to have this as often as > >>every second run. Would it not be sufficient to have a run range > >> index (either in file) or in some > >>db/txt file that would indicate what eff file to pickup? > > > > The "every second run" idea appeared only in the context of > > 2A3450 settings for which my list contains 186 runs. > > It turn out the the macro MapEfficiency.C can merge only 176 runs > > (if the run list exceeds 176 it fails and I couldn't find > > what is the problem). For this setting I just removed the last 10 > > runs and feel quite confident. > > > >>I suggest you prepare a short proposal for how to deal with this, > >> particular now where many different > >>people are using > > > > I hope that the answer to your first question contains the > > proposal with the instruction for the > > existing solution. As I remember the solution was made after some > > discussions with Steve. > > > > Because the instruction I'm sending the mail to the brahms-dev. > > The README file will be provided soon. > > > > Cheers, > > Pawel. > > > >>---------------------------------------------------------------- > >>Flemming Videbaek > >>Physics Department > >>Brookhaven National Laboratory > >> > >>e-mail: videbaek_at_bnl.gov > >>phone: 631-344-4106 > >>cell: 631-681-1596 > >>----- Original Message ----- > >>From: "Pawel Staszel" <ufstasze_at_if.uj.edu.pl> > >>To: "flemming videbaek" <videbaek_at_bnl.gov> > >>Sent: Thursday, August 17, 2006 6:55 AM > >>Subject: 2A3450 p+p_at_200 > >> > >>>Dear Flemming, > >>>I'm doing efficiencies for run05_pp and found something that may > >>> count for what you are doing with > >>>the pion's asymmetry, namely for settings 2A3450 runs from 14392 > >>> to 14425 have about 81% efficiency in T4 > >>>and for runs 14457 to 15801 T4 efficiency is about 97%. For > >>> polarity B the efficiency is stable on the > >>>level of 97%. The problem is that 2A3450 has a lot of runs ~200 > >>> and my macro that > >>>merges all runs in to the maps fails with such a big number. I'm > >>> just trying to find the problem. > >>> > >>>Maybe the solution will be to take each second run which should > >>> keep a proper representation for efficiencies. > >>>Any way my idea is to deliver the that will reflect average > >>> efficiency in the whole set of runs. > >>>If you have other ideas lest me know. > >>> > >>>Cheers, > >>>Pawel. > >>> > >>> > >>>-- > >>> --------------------------------------------------------------- > >>>------- > >>> > >>>| Pawel Staszel > >>>| | Jagiellonian University > >>>| | Institute of Physics email: > >>>| ufstasze_at_if.uj.edu.pl | Reymonta 4 > >>>| phone: (+48) 12 663 5705 | Krakow 30059 > >>>| FAX: (+48) 12 633 7086 | Poland > >>>| | > >>> > >>> --------------------------------------------------------------- > >>>------- > > > >-- > > ----------------------------------------------------------------- > >----- > > > >| Pawel Staszel > >| | Jagiellonian University > >| | Institute of Physics email: > >| ufstasze_at_if.uj.edu.pl | Reymonta 4 > >| phone: (+48) 12 663 5705 | Krakow 30059 > >| FAX: (+48) 12 633 7086 | Poland > >| | > > > > ----------------------------------------------------------------- > >----- > > > > > > > >------------------------------------------------------------------ > >------ > > > >_______________________________________________ > >Brahms-dev-l mailing list > >Brahms-dev-l_at_lists.bnl.gov > >http://lists.bnl.gov/mailman/listinfo/brahms-dev-l -- Catalin Ristea--------------------------------- High Energy and Heavy Ions Group Niels Bohr Institute Blegdamsvej 17, 2100 Copenhagen, Denmark Tel (+45) 35 32 54 04 / Fax (+45) 35 32 50 16 E-mail: catalin.ristea_at_nbi.dk http : www.nbi.dk/~ristea ----------------------------------------------- _______________________________________________ Brahms-dev-l mailing list Brahms-dev-l_at_lists.bnl.gov http://lists.bnl.gov/mailman/listinfo/brahms-dev-lReceived on Fri Aug 18 2006 - 14:05:58 EDT
This archive was generated by hypermail 2.2.0 : Fri Aug 18 2006 - 14:06:21 EDT