GSI Helmholtzzentrum für Schwerionenforschung
[FIXED] Problems with photon reconstruction in pandaroot
Dear all, I would like to point you on a problem which I have found in the past weeks, using pandaroot, in the photon reconstruction. When I try to reconstruct a decay chain to charged particles, basically the macro runs and delivers *reasonable* results. Recently I tried to reconstruct 3 mesons of the DsJ family: Ds2535+, Ds2460+, Ds2317+. In the decay chain of Ds2371+ there is only one pi0(-->gamma gamma); the reconstruction is going very slow, but in the end I managed to run my analysis macro over 5000 generated events. It took many hours (~70 h), and in the end the memory used was going up to to 70%...so to split 5000 events in 1000-event-jobs help; but this is not a solution, in my opinion. It has been a warning that something in the photon reconstruction has not worked properly. Of course, I can run in parallel 5 jobs of 1000 events each one, and in ~7-8 hours I get ready my root files and merge them. In the decay chain of Ds2460+, 3 photons got involved, as we have a pi0 (-->gamma gamma) and a photon in the decay of Ds*+. The decay chain is written on the top of the macro which I attach here. In this macro I commented out all kinematic fit, mass constrained fit, combinatorial: I am just trying to reproduce the full truth matched value of the invariant mass distributions and the momentum of the particles. Very easy. What comes out is that I can run this macro only up to 10 events (--->36% memory used). When I try to run 15 events, the memory grows abnormal up to 80% in a few seconds, and then my job is stopped after 20 seconds. It is not possible for me to reconstruct more than 10 events for the decay chain of the Ds2460+ right now, in the main decay of interest, just because it involves 3 photons. Here definitively something is going wrong with photon reconstruction, because when I tried to reconstruct the Ds2460+ only to charged particles, it worked smooth. Did anybody of you tried to reconstruct a decay channel where more than 2 photons got involved? If yes, what is your experience? I am using pandaroot rev-21003. Thank you in advance for any feedback, Elisabetta
Re: Problems with photon reconstruction in pandaroot
Dear Elisabetta, there was a bug in RhoFactory in combination with RhoCandidate causing this memory leak (and some older related to PndPidProbability, which should already be fixed in your rev). Could you update the rho folder (and maybe also PndTools/AnalysisTools) and try again, whether the memory leak vanishes? Concerning issues with neutrals, the point is, that there are always many gamma candidates in each event. You could produce a plot of gamma.GetLength(), and for sure you will see in average many more gammas than expected due to your signal channel. Therefore you might think about requiring some minimum energy for your gamma candidates in order to reduce combinatorics. Considering your macro code, you need to set the type of your pi0 list actually before you use it for further combinatorics, otherwise the MC truth match won't work I guess. Best, Klaus
And what I forgot in my previous posting, you should definitely apply a reasonable cut on the pi0 mass (not +-150MeV, but something like +-20 MeV), otherwise your Ds2460-list will probably be very long.
Dear Klaus, I do not use any mass cut when I ask for truth matched values of the particle, and I guess it is correct like so. Whci code is crashing only because the mass cut around the invariant mass of 2 photons is larger that 20 MeV/c^2? None. The mass selector which you have seen in my macro is there, at the end of the ftm_block, but it is not used; it is there just because there was much more in that macro, but I gave in the forum the easiest version. It was used just BEFORE and not AFTER teh vertex fit of the various pi0, Ds* was done. Clearly it is not possible in this conditions to apply any fitter. You would not get neither one entry before the memory leak stops your job. You can try yourself. Even if I apply a mass cut of +/- 20 to the invariant mass of the first 2 photons, it is absolutely non-influent on the memory leak that is created. You can try yourself. In addition, even if I apply any cut on energy, momentum, whatever in that macro, it is not going over 10 events. Even more: is you try to set up additional cuts in that macro: the memory leak occurs at the event 5 and not 10. Would we understand that here we got a problem? It is not possible to reconstruct in pandaroot (my personal experience) channels where more than 2 photons are involved. Please, try yourself and you will see. Pandaroot does not work fine with neutrals. Thanks for your feedback, Elisabetta
Klaus, sorry I forgot to ask: which revision do you suggest to use for the Rho package? Thanks, Elisabetta
I think you can just update to newest version of trunk. I also observed this severe leak in the last weeks, and I think I finally found the bug and fixed it... Technically it was related to the std::vector for the daughter pointers in RhoCandidate, which was not cleaned properly in RhoFactory. Best, Klaus
If you put also the sim macro and the dec I can try to reproduce your problem.
Hi again, I just ran your analysis macro for 500 events within 35 seconds, with the tiny modification of requiring a gamma energy of 50 MeV beforehand. This reduces the combinatorics tremendously and thus gives a decent speed up. So I would summarize: - There have been quite some bugs in the analysis tools, but fortunately most of them could be fixed meanwhile, thanks to the feedback from all of you. - Yes, indeed we have (too) many clusters stored as gamma candidates from the EMC. - With an appropriate treatment (minimum energy, mass windows for pi0 etc) things seem still to be feasible. - We nevertheless have to tackle the problem with the huge number of neutral clusters in the reco, stored as gamma candidates. Maybe properly setting up the 'RhoGoodPhotonSelector' is the most natural cure. The class already exists in rho/RhoSelector but is not adapted yet for our purpose. So some studies still would be necessary. Best, Klaus
Hello Klaus, thank you to take care of this, too. I updated my Rho package to the revision 21598. Without using any mass selection for the ftm_block, I get a little improvement in the percentage of memory used, but I do not manage to run neither 100 events. If I apply some basic selection cuts, such as the maximum number of photons per event (e.g., I fix gammas.GetLength()<50) and/or on the momentum of the photons (not smaller than 100 MeV/c), of course I get much Much less entries per event. But I am stacked still in problems of memory leaks, here. Would you please share your test-macro with me, so I can try myself and see how you set up the RhoSelectors for the energy, momentum, number of photon per event? Thank you very much for your help, Elisabetta
I have tried with my trunk 21608. If i use the macro as it is, to run 100 events it takes a lot of time, something like 7 minutes. Using an energy selector from 20 MeV, as suggested by Klaus: theAnalysis->FillList(gammas, "Neutral"); double E_min = 0.02; // your energy threshold RhoEnergyParticleSelector *GamEnSel=new RhoEnergyParticleSelector("gam",E_min+50.,100.); gammas.Select(GamEnSel); less than 20 seconds. It removes a lot of low momentum background.