Based on evidence that production jobs can get hung in track-finding for events with Limiting production of events with large hit counts, I propose a new database table to control the skipping of such events. At this point, it seems to me only necessary to have a single parameter in the table: an integer indicating some total maximum number of hits. This should be in the database instead of as a fixed parameter as it should be a number which changes depending on the dataset. A value of 0 would turn off the restriction (i.e. no maximum limit).

I also propose that the maximum should be a maximum on the number of hits within any given TPC sector. This "localization" of the excessive hits will have a more direct connection to tracking, which would, for example, be much more affected by 100k hits which are all in one sector than the same number of hits distributed over all 24 sectors.

One suggestion had been to use as a limiting parameter a maximum fraction of the total possible hits. While the limitation should take into account the fraction of live TPC within a sector, the fraction of total possible hits is a bit less straightforward. It involves considering several factors:

• Number of time bins recorded (currently 400, but wasn't always the case)
• Length of time the gated grid takes to open (could change with new GG drivers, for example)
• Whether prompt hits are recorded (changed with the use of TPX electronics)
• Tune of ALTRO parameters (changed a couple times already)

With this potential volatility, I think it is unwise to attempt to calculate the total possible maximum hits in code. Instead, the persons who fill this number in the DB should do so with consideration of the TPC operating conditions for a given dataset.

Update: Dmitry suggested a second field to contain a comment noting the considerations used in determining the maximum. A 255 byte TINYTEXT field seems common practice, and could be a URL of an explanatory web page, for example.

As this pertains to tracking, I propose the table be placed in: Calibrations_tracker / tpcMaxHits

In this manner, if we develop similar tables for other tracking subsystems (e.g. IST, Pixel, SSD, FGT, FTPC), they would be placed similarly under Calibrations_tracker.

Update (2011-03-07): Additionally, in RT ticket 2099, we learned that reconstruction jobs can get similarly stuck due to TPC hits which start at time bin 0. I propose to update the tpcMaxHits table (because these these cuts serve very similar uses in the code) to include another field for the maximum number of time bin 0 hits. This maximum will be scaled by the portion of live detector in StTpcHitMaker just as the maximum hits per sector.

Proposed (and now current) idl file:

/*    tpcMaxHits.idl
*
*  Table: tpcMaxHits
*
*       description: limit reconstruction of events with excessive TPC hits
*/ 


struct tpcMaxHits { 

   unsigned long  maxSectorHits;   /* maximum hits in a sector */
   unsigned long  maxBinZeroHits;  /* maximum hits starting at time bin zero */
   char           comment[255];    /* considerations in determining max */

 };

Thanks,

-Gene