Description of the problem: big memory usage in reconstruction of AuAu 200 GeV hijing central events. The memory growth seems to be due to unusually large number of Xi candidates which also correlates to unusually large number of V0s. Not all events show this behaviour but they correlate precisely with events where multiple primary vertices are found. However, in this case (simulation), there are no pileup events so there should not be 2 primary vertices. The sample used in this study is at /star/rcf/simu/rcf1296_02_100evts.fzd.

"Zero Order" plan: our very first approach to this problem was to try to identify the "good" and the "bad" events, and then keep only the good ones. To evidenciate the problem we looked at the decay lenght distribution of the V0s. As can be seen in the plots below, there are peaks at decay lenght values greater than zero, which can be the result of a real primary vertex being misidentified as a large number of V0s.

In order to classify the events as "good" or "bad", we looked at the properties of the distribution of the difference between the positions of the V0 and the primary vertex in z direction (v0z-pvxZ) for the first 500 V0s in each event. This way, we found that, for the sample studied, we can identify all bad events by requiring that the position of the maximum of the distribution is greater than 3 (Abs(max(v0z-pvxZ))>3). The reason why we chose the position of the maximum is because it separates the events much better than the mean or median of the distributions, i.e., it is less affected by outliers effects, which are relevant due to the small size of the sample (only 500 entries). Below there are two events we have selected to illustrate the procedure.

Doing this we could identify the bad events early (not sure if it is early enough, still investigating) and throw them away. However, at least for the sample studied (100 events), half of the events are bad and it is too many events to be thrown away. Also, we still do not know how this cut would affect real events, tests need be performed.

Looking deeper into the problem: as pointed out by Gene, the events where the problem appears are strongly correlated with events where multiple primary vertices are found. We also noted that the number of tracks used in the primary vertex finder differs between good and bad events by almost two orders of magnitude, which seems to be a strong indication that the primary vertex used in the bad events is the wrong one, actually, it is not even a primary vertex. In the code StSecondaryVertexMaker/StV0FinderMaker.cxx, the vertex used is the default one, and we are not sure which primary vertex is returned when the event has multiple vertices. We are studing the codes but it is still not clear for us what are the criteria to choose a primary vertex in the StEvent::primaryVertex() function, but it seems that it has failed for these central hijing events.

Just to check, we also looked at the primary vertex ranking distribution and the number of tracks used in the primary vertex (see plots below). We do not really understand what the vertex ranking means, but we were wondering whether the ranking and/or the number of tracks used to find the vertex are considered to choose the default primary vertex.

Possible solution: from the plots above we see that we can try to use these informations to reevaluate the primary vertex returned to the StV0FinderMaker, and if the vertex does not satisfy some cuts (to be defined), we change to the next one. In principle, it could solve the memory problem, because if the correct primary vertex is used, the StV0FinderMaker would not get lost with lots of fake V0s. This procedure is still under tests and can be applied in the StV0FinderMaker::Prepare(), by performing a loop over all possible primary vertices before go on, but we are not sure about the impact of it in the final data analysis, since the vertex used in the StV0FinderMaker may not be the default one. A more appropriate solution, perhaps, would be to review the criteria used to choose the default primary vertex but, of course, the impact of such change must be carefully studied.