First test for a pp "rapidity gap" trigger

8-APR-2013

We made the following request to the Trigger Board:

On Fri, 5 Apr 2013, Ramiro Debbe wrote:

Hi Akio,
Out of the analysis of the two runs we collected with the pp500_upc_2013 configuration and its single pp_upc trigger, we have indications that by changing the threshold in TOF hit multiplicity from 2<=TofHit<=6 to 3<=TofHit<=8, and recording tracks in the TPC we would be able to collect two prong events.
We also identified the benefits of including hits in one of the VPD counters to reduce noise without restricting our physics reach. Finally, we would also like to test the inclusion of signal from the MTD in a back-to-back trigger based on TOF "sectors".
It would be great to be able to define more than a single trigger in order to minimize the numbers of tests, the triggers would be:
a) Tofmult>2 and Tofmult<9  Veto BBC small tiles
b) Tofmult>2 and Tofmult<9  Veto BBC small tiles and VPD East
c) Tofmult>2 and Tofmult<9  Veto BBC small tiles TofSector5 and TofSector2  and MTD (one hit)

To proceed with these test we also need the information from the TPC, we would also request to be able to run, as before, at the end of the store but to keep the TPC operational.

p.s. As the present store is going to be dumped soon, the easiest thing to do would be to change the Tuf multiplicity settings.

Thanks
Ramiro

-------------------------------------------------------------
Visit this STAR HyperNews message (to reply or unsubscribe) at:
http://www.star.bnl.gov/HyperNews-star/protected/get/triggerboard/866.html

The request for TOF multiplicity for the second trigger (b) has been slightly modified and now reads Tofmult>1 and Tofmult<7

The argument I make for trigger (a) is based on our expectation that eventhough we require 3 or more TOF hits we will have some fraction of two-prong events:

Hi Akio,
You are right,  let me concentrate on the change of Tofmult thresholds. I'll leave to Leszek to clarify the VDP inclusion.
The result I reported in my blog page had the condition 4=<Tofmul=<6 and it would produce a reduction in rate of ~17 . If we implement that threshold we would be triggering at ~6kHz. With a scaledown of 50 we should reading at a confortable rate. A ten minute run at 120Hz will give us a big enough sample to look for two-prong events. According to tne plot I made reading the data with a raised Tofmult threshold, one third of the events collected in collision bunches will be all noise. One sixth of the remaining events will have two noise hits. That leaves us with a sample of ~2500 events with possible two-prong" events.
Ramiro 

and Lezcek made the argument in favor of adding one VPD to our existing trigger (b):

Hi Akio,

  Generally double rapidity gap events are with following topology

p + p --->    Y_1 (rapidity gap) X (rapidity gap) Y_2

X - is predominantly single particle decaying into two-prong final
state.
In proposed trigger X is seen as activity in ToF (#TOF>=2)
Rapidity gaps are required by .not.BBCE * .not. BBCW
States Y_1 and Y_2 can be unobserved protons (~ 90% of cross section)
but also "excited protons" which decay into 2,3- body final state.
Some fraction of "excited protons" gives signal in VPD but not in BBC.

So the presence of hits in VPD is still consistent with double rapidity
gap topology and coincidence of ToF and VPD reduces significantly
fraction
of events with noisy ToF

So the second trigger chain is

  1<#ToF<7(9) * .not. BBCE * .not. BBCW *  VPD

VPD can be east, west, east or west

In case of east or west estimated trigger rate from previous run is 2 k
Hz
so scaledown of 20 could be fine to collect enough events during 10
minutes run.

We already agreed on that within the UPC group.

Leszek

Leszek's work on including VPD information can be summarized with two figures extracted from our first run with collisions 14092072:

From an original sample of 10K events the addition of the requirement of "non-zero vpdEarliestTDC value on east OR west"  216 events are selected. A 98% reduction!

========================================================================
========================================================================

4-APR-2013

Raising the TOF multiplicity from tofHits>=2 to tofHits>=4 would reduce the rate of the trigger by a factor ~17 and clean up the sample:

This time the "abort gaps" show their actual utility; one third of the events in collision bunches must be produced by random coincidences in the TOF detector.
It looks like we still have some hope of using the simple trigger we started with. The physics of these events is more restricted but it may be equally interesting.
Before we switch to more complicated triggers involving back-to-back topologies complemented with MTD signal. I will try a run with a raised tofHits threshold.

=====================================================================================
=====================================================================================

Yesterday we collected data with a single trigger defined as follows:


in run 14092072. The main result of this run was apparent in the first seconds: the trigger rate was so high as to make the trigger system dead for 90% of the time.

The activity of the trigger  in each bunch crossing is shown below:

The so called abort gaps are just below 40 and 120 (more details later). The trigger is clearly more efficient in the abort gaps because, in the abscence of collisions, the BBC veto is always satisfied and TOF fires on noise. The collision bunches do show activity but at a rate that seem to indicate that it is mostly noise.

The number of TOF hits seen by the trigger during this runs are shown below:

and the corresponding multiplicity in each TOF tray:

During the run with collisions all trays appear to be mostly equally populated.

========================================================================================

We have also taken data with no beams in the machine (run14093058) and exactly the same detector and trigger conditions as the previous run and the trigger was equally overwhelmed (90% dead):

The distribution of bunch crossings is now uniformely populated:

This time the abort gaps cannot be seen above the collision bunches,

The multiplicity of TOF hits:

and the tray multiplicity:

The fluctuations are way bigger that the statistical errors, that means not all TOF cells were created equal, some are noisier than others,  but the active ones seem to be all over the place.
I think this does not bodes well for the use of TOF as part of this trigger (or the UPC_topo).