Hits in both microscope and tagger during CPP

[Elton Smith]

Dear Software Help,

I suspect Richard should take a look at this. Before I get to my issue/question, I need to give a little background. 

As a reminder, we have moved the microscope to cover the coherent peak at 6 GeV (instead of 9 GeV). At this position, we will often have degraded electrons hitting both the microscope and the hodoscope planes (in this region the hodoscope is sparse so not every electron should have hits in both counters).  See below for details of the simulation, but  they are not too important for the issue I am raising.

With the default hdgeant4, only microscope hits are recorded in the output (in the overlap region). I have tracked this down to code in GlueXPseudoDetectorTag.cc (line 137). If a hit is found in the microscope, it does not search the hodoscope. (See relevant code below) If I change the ‘else if’ statement to ‘if’, both microscope and hodoscope hits appear in the output. A screenshot of the output with both microscope and hodoscope hits is also given below. 

ISSUE: In the screenshot below you will see that both the truth information and regular hit info are exactly the same for the microscope and the hodoscope. The TRUTH info should be the same, but the smeared hit should be slightly different between microscope and hodoscope. This is where my questions/comment comes in. I believe the problem is that the code uses the single variable ‘E’ for both the microscope and hodoscope. However, they should be different based on the geometrical sizes of microscope and hodoscope counters. I could, of course, simply define two variables ‘Em’ and ‘Eh’. However, this code is complicated by the fact that the simulation is combining multiple MC energies into a single microscope of hodoscope hit. It would be best for an ‘expert’ to take a look at this and update the code for dual hits in the two detectors.

Additional note: In the hd_dump output, we only get a single DBeamPhoton, as it should be. It always takes the hit from the microscope (based on viewing a dozen events), which is probably also the desired output. Nevertheless, we also check the analysis code that computes the DBeamPhoton and combines the microscope and hodoscope hits correctly.

Thanks, Elton.

—————————————

Additional notes for interested parties:

I have simulated events based on the BH muons that were generated/processed by Richard and Andrew. The simulations were produced running MCWrapper interactively (1000 events produced). If anyone is interested in the details, all files can be found on the work disk at 

ifarm1802:gen_BH>pwd

/w/halld-scshelf2101/halld2/home/elton/gen_BH

The output files are located in 

ifarm1801:hddm>pwd

/w/halld-scshelf2101/home/elton/gen_BH_mar2022/hddm

------------------------------------

Elton Smith

Jefferson Lab MS 12H3

12000 Jefferson Ave STE 4

Newport News, VA 23606

(757)269-7625

[Elton Smith]

HI Richard,

Thanks for taking a look at this. 

Did you push your branch to the repository? I cannot find your branch, which I assume is under JeffersonLab/HDGeant4.

Thanks, Elton

------------------------------------

Elton Smith

Jefferson Lab MS 12H3

12000 Jefferson Ave STE 4

Newport News, VA 23606

(757)269-7625

On Apr 11, 2022, at 8:34 PM, Richard Jones <richard...@uconn.edu> wrote:

Elton,

In my comment about mcsmear, I misunderstood your suggestion. Indeed, when I looked at the code (that I wrote) in GlueXPseudoDetectorTAG.cc I understood better what you were suggesting. Can you have a look at the new HDGeant4 branch overlapping_hodo_micro_ranges_rtj and confirm that this does what you were hoping?

-Richard Jones

On Mon, Apr 11, 2022 at 5:27 PM Richard Jones <richard...@uconn.edu> wrote:

With the default hdgeant4, only microscope hits are recorded in the output (in the overlap region). I have tracked this down to code in GlueXPseudoDetectorTag.cc (line 137). If a hit is found in the microscope, it does not search the hodoscope. (See relevant code below) If I change the ‘else if’ statement to ‘if’, both microscope and hodoscope hits appear in the output. A screenshot of the output with both microscope and hodoscope hits is also given below. 

This is a good point. This "else if" should be changed to "if" now that there is overlap between the ranges of the hodoscope and microscope.

 

ISSUE: In the screenshot below you will see that both the truth information and regular hit info are exactly the same for the microscope and the hodoscope. The TRUTH info should be the same, but the smeared hit should be slightly different between microscope and hodoscope. This is where my questions/comment comes in. I believe the problem is that the code uses the single variable ‘E’ for both the microscope and hodoscope. However, they should be different based on the geometrical sizes of microscope and hodoscope counters. I could, of course, simply define two variables ‘Em’ and ‘Eh’.

 

At present we do not "smear" the tagger energy in mcsmear. We could do, but at present we don't. This could be added by taking the middle energy of the tagging counter hit in either the TAGM or the TAGH. That would make sense to do, although it would not make much practical difference because the width of the counters in either the TAGM or the TAGH is much smaller than the final state energy resolution in the GlueX spectrometer. If you agree, I wiill introduce code to mcsmear that does this, and stick it in a test branch. I will send you an email with the name of the branch so you can test it out.

 

However, this code is complicated by the fact that the simulation is combining multiple MC energies into a single microscope of hodoscope hit. It would be best for an ‘expert’ to take a look at this and update the code for dual hits in the two detectors.

 

I don't think we ever want to contemplate "hits merging" between the microscope and hodoscope. This should be discouraged because of the difficulty of subtracting accidentals in the presence of both merged and unmerged tags. This is the infamous problem of the overlapping tagging counters that people have argued about since the beginning of tagged photon experiments. It can be solved, but it requires separately analyzing the overlap-hits and non-overlap hits and applying different accidentals subtraction rules to the two kinds of tags. The much simpler approach is to treat the hodoscope and microscope tags in this region as if they were independent, and not trying to merge them. Whatever cross section you are trying to measure would then have two independent sets of measurements, with the hodoscope points crossing through the microscope region and overlapping but not interfering with them. The fact that some of the same GlueX triggers would appear in both samples would not bias the individual results. 

Additional note: In the hd_dump output, we only get a single DBeamPhoton, as it should be. It always takes the hit from the microscope (based on viewing a dozen events), which is probably also the desired output. Nevertheless, we also check the analysis code that computes the DBeamPhoton and combines the microscope and hodoscope hits correctly.

We should get separate DBeamPhotons for each tag, one for each accepted TAGM hit and one for each accepted TAGH hit. One just wants to be careful not to confuse these by combining histograms with both kinds of tags in them, since the tagged photon flux is not only a function of the energy but also of whether it is the tagged flux in the TAGM or the tagged flux in the TAGH.

-Richard Jones

On Mon, Apr 11, 2022 at 4:49 PM Elton Smith <el...@jlab.org> wrote:

*Message sent from a system outside of UConn.*

<Tagger_hits.png>

<R71752_Ev501090_DoubleHits.png>

[Elton Smith]

Hi Richard,

Your edits look like they addressed the issue that I raised. Below is a dump of an event (comparable to the one I showed yesterday). You can see that now the microscope and hodoscope energies are (slightly) different as they should be. The TRUTH information is the same for both. A single DBeamPhoton entry is created tagged with the microscope hit. This is the behavior I would like to see.

If you submit a pull request, I will can approve it.   Thanks, Elton.