Hi, in yesterdays discussion, I showd that the data for delata delay for the tubes 25-28 in TOF1 was not there. Looking into the code BrTofDeltaDelayCalModule I found that the y-range (botTime - topTime) in the profile histograms was set to [-10,10] and this set of tubes happened to have 10 < botTime - topTime < 20 which led to an empty histogram. This problem appears when one tries to calibrate the spped of light in addition to the "delta delay". If one goes with the option of a fixed value from previous calibrations in AuAu, as Flemming suggested, one would not encounter the problem as the y-range (botTime - topTime) is set to [-20,20] May be one should think about making this range a parameter to be set from bratmain instead of having it hardwired. Selemon, -----Original Message----- From: Flemming Videbaek [mailto:videbaek@bnl.gov] Sent: Wed 5/24/2006 10:40 AM To: Bekele, Selemon; Catalin Ristea Cc: brahms-dev-l@lists.bnl.gov Subject: Re: [Brahms-dev-l] Acceptance Maps Hi Selemon, I did not catch this one when checking out, this may explain a swa a small jump of 1 Mb of memory used in my test (with only two vertex bins). Why don't you go ahead with the change and a version update of banapp. Flemming -------------------------------------------- Flemming Videbaek Physics Department Bldg 510-D Brookhaven National Laboratory Upton, NY11973 phone: 631-344-4106 cell: 631-681-1596 fax: 631-344-1334 e-mail: videbaek @ bnl.gov ----- Original Message ----- From: "Bekele, Selemon" <bekeleku@ku.edu> To: "Flemming Videbaek" <videbaek@bnl.gov>; "Catalin Ristea" <ristea@nbi.dk> Cc: <brahms-dev-l@lists.bnl.gov> Sent: Wednesday, May 24, 2006 11:33 AM Subject: RE: [Brahms-dev-l] Acceptance Maps Hi Flemming, I see that you have updated the method below to delete Double_t findAverageError(TH2F* h) { ... TH2F *trimedMap = static_cast<TH2F*>(h->Clone(Form("%s_trimmed", h->GetName()))); ... delete trimedMap; } I think we also need to put a delete statement in the method "checkThrownAccepted" too, which is not in the code in CVS. This may not cause a severe memory leak as the one above since it gets called about six times per vertex bin. Bool_t checkThrownAccepted(TH2F* hThrown, TH2F* hAccepted){ ... TH2F* tmp = (TH2F*)hThrown->Clone(); ... delete tmp; } Selemon -----Original Message----- From: Flemming Videbaek [mailto:videbaek@bnl.gov] Sent: Tue 5/23/2006 2:28 PM To: Bekele, Selemon; Catalin Ristea Cc: brahms-dev-l@lists.bnl.gov Subject: Re: [Brahms-dev-l] Acceptance Maps There is a severe leak - the most recent version of generate spectrum had in the checkAcceptance added a statement to make a TH2()->Clone() so every time the stat error is checked a new TH2F is added , and the mem is just growing, and growing and growing.. I introduces the needed change (delete ..) and will commit shortly -------------------------------------------- Flemming Videbaek Physics Department Bldg 510-D Brookhaven National Laboratory Upton, NY11973 phone: 631-344-4106 cell: 631-681-1596 fax: 631-344-1334 e-mail: videbaek @ bnl.gov ----- Original Message ----- From: "Bekele, Selemon" <bekeleku@ku.edu> To: "Catalin Ristea" <ristea@nbi.dk> Cc: <brahms-dev-l@lists.bnl.gov> Sent: Tuesday, May 23, 2006 12:58 PM Subject: RE: [Brahms-dev-l] Acceptance Maps > > Hi Catalin, > > I made acceptance maps with the same histogram sizes > for AuAu before the recent updates and had no problem. > If there is no memory leak, something must have changed. > I could try to do what you are doing, but still the jobs gets > killed even before one vertex bin is completed. > > Selemon, > > -----Original Message----- > From: Catalin Ristea [mailto:ristea@nbi.dk] > Sent: Tue 5/23/2006 11:18 AM > To: brahms-dev-l@lists.bnl.gov > Cc: Bekele, Selemon > Subject: Re: [Brahms-dev-l] Acceptance Maps > > > Hi, > > I've talked to Truls about this problem. I am not sure if there is a > memory leak, but definitely the size of the 2D histograms is big > (thrown/accepted + DS + pid). > > My work-around was to make different job/file for each vertex bin, > and then merge together in a single acceptance file, having the run > geometry on top. > This requires few lines into the acceptance code, that's all. > > But, if there is a memory leak, then we have more serious problems. > > Regards, > Catalin. > > On Tuesday 23 May 2006 18:05, Bekele, Selemon wrote: >> Hi, >> >> I have been trying to make acceptance maps >> for CuCu at 200 GeV. I am using code updated from >> CVS with all the current changes. All the jobs I submit >> get killed and running interactivly, I found out that >> the size grows to more than 1.5 GB while still working >> on the first vertex bin. >> -------------- >> NVtxBins = 16 >> Vertex bin #0 [ -40, -35 ], average error on pion map: >> Killed.23% >> -------------- >> >> An example from the condor jobs: >> >> 7094.0 tigist 5/22 18:28 0+04:03:36 I 0 1724.6 >> acc_cucu2B861_RICH.sh 7095.0 tigist 5/22 18:28 >> 0+04:03:33 I 0 1715.3 acc_cucu2B861_H2.sh 7111.0 tigist >> 5/22 18:29 0+16:00:03 I 0 1971.1 acc_cucu4A1723_H2.sh 7113.0 >> tigist 5/22 18:29 0+02:26:44 I 0 1027.6 >> acc_cucu4A2442_H2.sh >> >> Could there be a memory leak somewhere in the banapp code? >> >> Selemon, >> >> >> >> _______________________________________________ >> Brahms-dev-l mailing list >> Brahms-dev-l@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@nbi.dk > http : www.nbi.dk/~ristea > ----------------------------------------------- > > _______________________________________________ > 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 May 26 10:24:52 2006
This archive was generated by hypermail 2.1.8 : Fri May 26 2006 - 10:25:18 EDT