9/18/2015i. ravinovich1 hbd performance in run-9 i. ravinovich wis

04/21/23 I. Ravinovich 1

HBD performance in Run-9

I. RavinovichWIS

HBD milestones for Run-9

Reach a stable operation of the GEM modules Improve the transmission of the radiator Check the tracking and alignment Space gain equilibration in each module Reverse bias HV settings for each module Determine hadron MIP response in RB mode Determine “single” electron response Determine “double” electron response Determine hadron Cherenkov response


HBD operation during ongoing Run-9

There are almost NO trips which are related to the GEMs themselves. From time to time (very seldom) there are some trips related to noisy 1471N LeCroy PS. Will have a few spare soon.

There are NO trips due to the sudden gain increase related to the weather changes (P/T). We have 5 sets of HV settings for different P/T values, so HV software takes care of it between the runs if there a need for it.

Up to now we have 9 dead HV segments on 6 GEMs, 1 was there already at SB, 6 developed in the beginning of run, 1 in the end of March, 1 in the end of April. The resistors (for 8) have been changed, so the modules are fully operational. The “fresh” one will be checked during access tomorrow and hopefully fixed, so the EN1 module which did not work last week or so will be (again) hopefully operational.

Let me remind you that 1 HV segment is 3.6% of the module area, so 8 dead strips correspond to 1.4% of the PHENIX Central Arms acceptance.

One module ES1 is not operational due to the short between the mesh and top GEM. There is nothing that can be done. This module is on the edge of the acceptance, it corresponds to 2.5% dead area of it.


(2.5hrs. of flow thru cells)

HBD-Ar @ 2.25lpm (straight-through mode, no scrubbing)

HBD-CF4 @ 4.5lpm (Recirculation mode, incl. scrubbing)

The radiator transmission

Tracking and alignment

Used zero field runs. HBD was operated in

forward bias mode in order to see the hadrons MIP.

The reconstructed hadron tracks in Central Arms are projected to HBD.

Each module was aligned according to the matching in both directions.


Space gain equilibration

The module gain non-uniformity over the GEM area originates from the variations of the holes diameter coming from GEM production process, and the gain is a very strong function of the hole diameter. There is nothing that we can do rather than correct it offline for each particular module.


HV scans have been performed for each individual module tuning the drift field between the mesh and the top GEM in

each case


ES1 =-10VRed (+5V), black (0V)green(-5V),blue(-10V),rest(-15V and lower)

Hadrons MIP response

Runs in (+-) field. HBD in reverse bias. The reconstructed hadron

tracks in Central Arms are projected to HBD.

The residual dE/dx charge is very small wrt electron response that will be shown on the next slide, so there is no problem with hadron rejection.


Singles versus doubles.Single vs double electron response: used the electrons from

Dalitz pairs in the mass region below 150 MeV. The separation between isolated electrons and unresolved doubles is there. The number of p.e. is ~22, more than 50% increase wrt Run-7 value.


Cherenkov response of high momentum hadrons

Runs in (++) field. Reconstructed high momentum

hadrons (p > 5 GeV/c) are projected to HBD.

Their Cherenkov response is in place.


HBD electron efficiency

The idea is to extract the HBD single electron track efficiency from 500 GeV data of Run-9, at least check the method on this little statistics and then use it for 200 GeV high statistics run.

The best “tool” for that would be the low mass Dalitz pairs reconstructed in the Central Arms and then matched to HBD.

Ideally it would be good to use the resolved (in HBD) Dalitz pairs but at the moment we do not have enough statistics, they are mostly (~80%) unresolved. The 200 GeV run will provide it.

The weakness of this “tool” is that before doing that we have to reject as many conversions as possible.


Conversions in (++) field: MC and dataThe sharpness of phiV distribution is dictated mainly by the conversions in HBD backplane and in the

air since they do not suffer from multiple scattering before reaching DC. The big fraction of the conversions occurred in the beam pipe and in HBD radiator are bent by the magnetic field not

reaching the Central Arms. So, in the analysis there is no problem to reject most of the conversions using relatively small phiV cut while preserving a relatively high efficiency for the other signal pairs.

For instance applying a phiV cut of 0.6 radians will result on rejecting of ~90% of the conversions while preserving ~80% of the signal.


Conversions in (+-) field: MC and dataHere the picture is completely different. The phiV distribution is much wider due to: 1) different

magnetic field; 2) a big fraction of the conversions occurred in the beam pipe and in the HBD radiator reach the

Central Arms suffering from multiple scattering in the HBD material. For instance applying a phiV cut of ~0.6 radians we can reject only ~50% of the conversions. Of course a good fraction of the

remaining conversions will be rejected by vetoing on HBD but not those that produced the signals in HBD. But since many of the conversions in the HBD radiator produce a single pad clusters we can reject those in the offline analysis, this needs to be studied. For the efficiency study I used a mass

window of 25 < m < 50 MeV.


HBD efficiency

Used the low mass range where the number of the conversions is relatively small and where the combinatorial background is negligible, namely0.025 < m < 0.050 GeV.

Count the number of reconstructed pairs in this mass window in the Central Arms.

Then match them to HBD and count. The division of the above two numbers

is a HBD pair efficiency wrt Central Arms.

With this little statistics we can declare that HBD single electron track efficiency is ~90%. More exact number will be derived from high statistics 200 GeV data.


First look at 200 GeV ERT data

CNT_ERT files produced by Todd in 1008, 167 physics runs out of 277 so far recorded by PHENIX.

Standard eID cuts used by many analysis done for p+p collisions.

The analysis which uses HBD is very simple one:1. Reconstruct all clusters in HBD using simple

clustering algorithm and create their list.2. Project the electron from reconstructed in Central

Arms pair (or just a single electron) into HBD and match it within 3 sigma matching cuts. In this step all electrons that are produced outside HBD radiator (mainly originating from conversions) are rejected.

3. The next 2 steps are the rejection of the combinatorial background from “partially” reconstructed in the Central Arms conversions and Dalitz decays: a) if one of the legs of reconstructed pair is matched to a double amplitude (charge) cluster this pair is removed; b) if near one of the matched cluster there is a close hit (within a certain distance) and this hit does not match to any electron in the Central Arms then this pair is removed.


How about HBD software?

There is no need for a complete set of HBD software ready for a full production of 500 or 200 GeV data.

What will be written (as it was done for Run-7 data production and now, for Run-9 test production in 1008) is only “HbdMiniCellList” which contains a minimum information about each fired pad for the further use of the clusters reconstruction.

As I mentioned previously the local pad to pad gain equilibration constants are in the DB.

HBD is part of OnCal, so the gains for each run and for each module are being written to DB during the ongoing run or the further time (P/T) correction.

The next step (call it “afterburner” if you like) is to read EWG and HBD output streams, reconstruct the HBD clusters, match them to the electrons from EWG and do the analysis like one that I showed on previous slide for example.

The clustering code: there is one that I’ve written for Run-7 data and now I use it for the performance check tests. Some time ago Tom H. proposed a new one and we very much hope is a better one. Sky R. (who has been working on this code) is close to commit it to CVS, but first he would like to intensively test it and compare with the results that we got with the present code.

MC: the full HBD geometry is in PISA as you have seen from my MC study on conversions. The slow simulation exists, needs to be checked, it was not touched since several years.

I would guess that’s all that I wanted to tell you about HBD in Run-9. Next slide pls:

I. Ravinovich 16

Mixed events background and MB sample

Do we accumulate enough MB triggers for our needs in general and for the mixed events background

determination for low mass dielectrons measurements in particular? Right now (according to John) the MB triggers

rate is ~10% of the total bandwidth.

There are two factors related to the statistics for the combinatorial background subtraction. The first one is the statistical accuracy of the absolute normalization of the unlike-sign combinatorial background. It is dictated by the number of like-sign pairs from the same events in the mass interval you have chosen. Usually it is not an issue: PPG088 quotes for p+p ~3% which is good enough when the signal to background ratio is not as bad as in Au+Au where we need much better accuracy. The second factor is the number of those generated unlike-sign pairs which we (after normalization) subtract from the foreground unlike-sign pairs. If we have generated the infinite number of such pairs it does not play any role, we just leave with the statistical uncertainty of foreground pairs which are from the triggered events. Is it in issue to generate enough pairs with ~10% rate of MB triggers?

Such mixed events background is constructed from the MB data set requiring that at least one electron/positron fulfilled the ERT trigger condition. So we reduce our 10% MB sample by additional factor which is not small We usually apply the vertex cut (50% reduction if the vertex cut is +/- 30cm). Then in Run-9 we have HBD with its own rejection, so we have an additional factor on top of previous reduction. Let’s see the numbers.


Mixed events background in Run-9

The trigger efficiency not (yet) aplied. We have to define the depth of the pool: for Au+Au we

use 20, for p+p I do not know what has been used. One can simply scale with the multiplicity and use 2000 but that would be true if we would analyze the MB data.

I’ve varied it from 20 to 20000. The statistics is based on 0.179E9 MB triggers produced in 1008, after +/- 30 cm cut I left with 0.091E9 triggers.

Up to 2000 the number of pairs just scales with a buffer size but then not, looks like there are not enough events.

So, let’s look at “20000” numbers: in Central Arms only the mixed events adds 10% to the statistical uncertainty of the foreground pairs but after HBD cuts it almost doubles the error. And this is an integrated spectrum. Then we would like to look at different pT, different mass region etc, it is known that HBD works better with tighter vertex cut of +/- 20 cm and having the statistical fluctuations on the generated background (as you see it on the right plots) is not so good.

Can we leave with it? It is hard to say. I would guess (I hope) that till the end of the run we will triple the statistical uncertainty both for the foreground and background pairs.


9/18/2015i. ravinovich1 hbd performance in run-9 i. ravinovich wis

Documents

module area

module es1

individual module

particular module

en1 module

gem area

reconstructed hadron

hadron rejection