Ambiguous Associations

The situation gets considerably more complicated when we consider ambiguous associations. They can easily be generated in this demonstration just by opening up the time gate:-

$tca_time_gate -20000. 20000.
@tca_demo

produces:-

      Output: File: tca_demo_out.ntp
              N-tuple ID:    201
              No. of entries written:          36

and a plot of del_time shows a spread of times from -19000. to 11000.

TCA can be instructed to limit the ambiguity i.e. the number of times an event is used as a primary using the $TCA_AMBIG_REQ command. Try:-

$tca_ambig_req 1
$tca_time_gate -20000. 20000.
@tca_demo

which will only output any event as a primary once as the output confirms:-

      Output: File: tca_demo_out.ntp
              N-tuple ID:    201
              No. of entries written:          10

However the plot of del_time may come as a bit of a shock. TCA has not always taken the association with the smallest absolute del_time. This comes about because of the way TCA works. It does not output associations as it finds them. Instead it collects all the associations for a given primary into a buffer and then outputs as many as are required by the $TCA_AMBIG_REQ command. It does this to allow the user to sort associations according to some value and only to output the best ones, which may not necessarily be the first it comes across. To demonstrate how this works it is time to look at the TCAR 202 bank in tca_demo_titles.dat:-

nhit_1       equals            nhit_1: 30. 30.;       
nhit_2       equals            nhit_2: 20. 20.;       
id_1         equals            ENTRY_NO_1;            
id_2         equals            ENTRY_NO_2;            
del_time     ntime_difference  time_jdy_1,time_jdy_2; 
_sort_on     abs               del_time;              
ambig        tca_ambiguity     ;                      
order        reserved          ;

This introduces two new features but for now we will concentrate on the _sort_on variable that records the absolute time difference. Once TCA has assembled all the associations for a given primary event, it looks to see if the n-tuple contains the special temporary variable _sort_on and, if so, sorts the associations into ascending order on it. Now limiting the ambiguity keeps the associations with the smallest value of this variable, in this case keeping the events that are closest together in time. To demonstrate this use:-

$tca_disable_ntuple 201
$tca_enable_ntuple 202
$tca_ambig_req 1
$tca_time_gate  -20000. 20000.
@tca_demo

which switches to the new TCAR bank and then operates as before. Plotting del_time shows that TCA has indeed kept the associations with the smallest time difference.

Ironically, we have only now reached the point at which we are ready to answer what is probably the first question you would think to ask: ``How good is the association?'' i.e. how often does it:-

1. fail completely
2. find an unambiguous match
3. find an ambiguous match

and for this we need a special DQF:-

ambig        tca_ambiguity     ;                      
order        reserved          ;

This stores, in the variable ambig, the number of times the event formed an association as a primary and, in the variable order, the position in the sorted list of this association, with 1 meaning the first entry i.e. best. TCA does not have the information to fill this out while the association is being formed, it must wait until all associations for the current primary have been tried. So initially these variables are left as undefined, and TCA only updates them just before output. So

Do not place cuts on the output variables of TCA_AMBIGUITY or use them as input parameters in later entries in the n-tuple: you will just be dealing with the undefined value!

For failing associations ambig is set to zero, so using:-

$tca_output_unass
$tca_ambig_req 1

will ensure that every primary will be output exactly once and then plotting the ambig variable will give a direct measure of how successful the association is.