[Halld-offline] Fwd: r9428 - trunk/sim-recon/src/libraries/TRACKING

[Paul Mattione]

Mark, this may prevent the job crashes you're experiencing with the data challenge(s).  I was having the same problem and this fixed it for me.  

Begin forwarded message:

> From: Hall-D.SVN.Repository at jlab.org
> Date: August 4, 2012 5:01:37 PM EDT
> To: davidl at jlab.org, brash at pcs.cnu.edu, wolin at jlab.org, zisis at uregina.ca, mashephe at indiana.edu, remitche at indiana.edu, zihlmann at jlab.org, somov at jlab.org, staylor at jlab.org, kmoriya at indiana.edu, pmatt at jlab.org, leckey at jlab.org
> Subject: r9428 - trunk/sim-recon/src/libraries/TRACKING
> 
> Author: pmatt
> Date: 2012-08-04 17:01:35 -0400 (Sat, 04 Aug 2012)
> New Revision: 9428
> 
> Modified:
>   trunk/sim-recon/src/libraries/TRACKING/DTrackCandidate_factory.cc
>   trunk/sim-recon/src/libraries/TRACKING/DTrackCandidate_factory.h
> Log:
> Added "MAX_NUM_TRACK_CANDIDATES" to the DTrackCandidate factory.  
> If more than this many track candidates (default=20, command-line configurable) are found, delete all of them.
> This prevents crashes from pseudo-instantaneous memory spikes due to swimming too many tracks (one for each PID, at both time- & wire-based stages).  
> 
> 


Although it's not ideal to just toss out events, 20+ track events are basically unusable for physics anyway.  Also, hopefully this won't be as much of a problem once I fix the low-momentum track spiral reconstruction.  If you want, you can set the parameter to -1 for there to be no maximum cutoff.  

Note that now 20+ track events and 0 track events are now indistinguishable.  We're working on a way to distinguish them, but it's not ready yet...

 - Paul

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.jlab.org/pipermail/halld-offline/attachments/20120804/de362712/attachment-0002.html>