[Halld-unique] Fw: [EXTERNAL] Re: Getting "true" beam photon in MC

Thu Jul 1 09:54:46 EDT 2021

Conversation with Richard, how to think about true beam photons in MC

________________________________
From: Richard Jones <richard.t.jones at uconn.edu>
Sent: Monday, June 21, 2021 5:34 PM
To: Jonathan Zarling <jzarling at jlab.org>
Subject: Re: [EXTERNAL] Re: Getting "true" beam photon in MC

Jon,

I guess I don't understand why there would be a distribution of peaks away from the main one at zero in the Delta t plot, in the absence of accidentals. Is there more than one entry per true beam photon in the plot you're thinking about? Like for different RF bunch guesses or something.

The RF signal does not tell you which beam bucket is the true one, it just tells you the precise time modulo 4ns. So this would give you an infinite series of spikes every 4ns. It is the trigger time that selects which RF bucket is the most probable one to contain the tag that corresponds to the triggered interaction. But the  trigger time resolution is only so good. Right now in the simulation I have set the trigger time resolution to 10ns rms. So that is why you get 10-15 spikes around t=0, with a spacing of 4ns in the simulation. The t=0 in the simulation is the simulated trigger time, not the time of the vertex. If you want to find the true vertex time, don't look at the tagger time, look at the true vertex time in the DReaction object.

-Richard Jones

On Mon, Jun 21, 2021 at 4:57 PM Jonathan Zarling <jzarling at jlab.org<mailto:jzarling at jlab.org>> wrote:

*Message sent from a system outside of UConn.*

Ah ok, thanks for clarifying. The plot I was showing is for events that make it into some analysis trees, so it's after the usual PID timing cuts, missing mass, kinfit convergence, etc. PID timing cuts only on the final state particles as far as I'm aware, I think this is eta->pi+pi-pi0 data.

Maybe a newbie question: I guess I don't understand why there would be a distribution of peaks away from the main one at zero in the Delta t plot, in the absence of accidentals. Is there more than one entry per true beam photon in the plot you're thinking about? Like for different RF bunch guesses or something.

Jon
________________________________
From: Richard Jones <richard.t.jones at uconn.edu<mailto:richard.t.jones at uconn.edu>>
Sent: Monday, June 21, 2021 4:28 PM
To: Jonathan Zarling <jzarling at jlab.org<mailto:jzarling at jlab.org>>
Subject: Re: [EXTERNAL] Re: Getting "true" beam photon in MC

Jon,

The statement I made was not for accidentals, only for the "true" beam photon. Here it is again, what you should expect in the absence of any accidentals, no random hits, just true tags.
If you were actually plotting the tagger times minus the RF time for physics events in simulation, you would get regularly spaced peaks every 4 ns, within a Gassian envelope with a sigma of 10 ns. That is, there would be a broad hump of 12-15 peaks, starting at -24ns, -20ns, -16ns, ... +16ns, +20ns, +24ns... and petering out as the peaks get more and more out of time with the trigger. Here in your plot I see the clear peak at 0ns, and maybe one at -4ns, -8ns, +4ns, and that is about it. What happened to all of the other peaks, I don't know. Some kind of PID timing cut?

-Richard

On Mon, Jun 21, 2021 at 4:15 PM Jonathan Zarling <jzarling at jlab.org<mailto:jzarling at jlab.org>> wrote:

*Message sent from a system outside of UConn.*

Hi Richard,

Right, so in the plot I sent I'm using the "Beam__IsGenerator" flag from the analysis library. So naively this is supposed to only be the "true" beam photon for the simulated event. The timing tails look suspiciously long to me: either an oversight in the Beam__IsGenerator determination or maybe getting the RF bunch wrong.

I suspect it's an over-acceptance in the Beam__IsGenerator flag though. The source code looks like it'll select anything that hits the right counter. I know you probably didn't write it, but could you have a quick look? Here's the link: https://github.com/JeffersonLab/halld_recon/blob/2c9a71a53e6ca9285be0d0d7e8a7afc9bd19e57c/src/libraries/PID/DBeamPhoton_factory_TAGGEDMCGEN.cc#L44<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam10.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttps-2D3A-5F-5Fnam10.safelinks.protection.outlook.com-5F-2D3Furl-2D3Dhttps-2D253A-2D252F-2D252Fgithub.com-2D252FJeffersonLab-2D252Fhalld-2D5Frecon-2D252Fblob-2D252F2c9a71a53e6ca9285be0d0d7e8a7afc9bd19e57c-2D252Fsrc-2D252Flibraries-2D252FPID-2D252FDBeamPhoton-2D5Ffactory-2D5FTAGGEDMCGEN.cc-2D2523L44-2D26data-2D3D04-2D257C01-2D257C-2D257C4054a828929b429041f208d934f15e89-2D257C17f1a87e2a254eaab9df9d439034b080-2D257C0-2D257C0-2D257C637599033547329146-2D257CUnknown-2D257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-2D253D-2D257C1000-2D26sdata-2D3DsMvlL6rxpnw7ysnAeoh2ehj4cdXqD6Sbu7OzsWqaaoM-2D253D-2D26reserved-2D3D0-2526d-253DDwMFaQ-2526c-253DCJqEzB1piLOyyvZjb8YUQw-2526r-253DmWHgh9kgeTdfLG7caifCQnkq64mj-2DZ8j5T6ci0QKA-2Dw-2526m-253D6MeCUMcWNvk-2DJvKgGqYI5bZKSV3RW3lyspsY0XfdVFI-2526s-253DOS-5F2L-2D-5FZEuToKGe4HWLfSYtd1v9joUVIAi0NtiQjP5k-2526e-253D-26data-3D04-257C01-257C-257Caad0a1786dd84cfedd4f08d934f728bb-257C17f1a87e2a254eaab9df9d439034b080-257C0-257C0-257C637599058427821955-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C1000-26sdata-3DVohy4CEmRk0vtC-252Bqnwatp-252B6ouxACaOXwfimWEHuu5-252BM-253D-26reserved-3D0&d=DwMFaQ&c=CJqEzB1piLOyyvZjb8YUQw&r=mWHgh9kgeTdfLG7caifCQnkq64mj-Z8j5T6ci0QKA-w&m=zdr6DX9pZAPq2llrU2gKCsEbiO0Kfhd0BviK969AC0I&s=x5A4ESnebMPSxMgi5G_oRS8r8D974hoM7nRqKaRmO7s&e=>

If it is overly accepting of candidates for the true photon, it's not really going to affect analysis to my awareness, but Beam__IsGenerator might inflate the true number by like 1% or so.

Cheers,
Jon
________________________________
From: Richard Jones <richard.t.jones at uconn.edu<mailto:richard.t.jones at uconn.edu>>
Sent: Monday, June 21, 2021 3:21 PM
To: Jonathan Zarling <jzarling at jlab.org<mailto:jzarling at jlab.org>>
Subject: [EXTERNAL] Re: Getting "true" beam photon in MC

Hello Jon,

I can tell you anything you want to know about the objects saved to the simulation and mcsmear output files. But once you get to the output from the ANALYSIS library, things have gotten pretty far removed from anything in the simulation.

If you were actually plotting the tagger times minus the RF time for physics events in simulation, you would get regularly spaced peaks every 4 ns, within a Gassian envelope with a sigma of 10 ns. That is, there would be a broad hump of 12-15 peaks, starting at -24ns, -20ns, -16ns, ... +16ns, +20ns, +24ns... and petering out as the peaks get more and more out of time with the trigger. Here in your plot I see the clear peak at 0ns, and maybe one at -4ns, -8ns, +4ns, and that is about it. What happened to all of the other peaks, I don't know. Some kind of PID timing cut?

-Richard Jones

On Sat, Jun 19, 2021 at 1:01 PM Jonathan Zarling <jzarling at jlab.org<mailto:jzarling at jlab.org>> wrote:

*Message sent from a system outside of UConn.*

Hi Richard,

I'm wondering if you might be able to help me out, I'm trying to pick out the "true" beam photon in MC and am scratching my head over the Beam__IsGenerator quantity. It's saved to analysis trees and I had hoped to use it to pick out the true beam photon. I was confused why there were some beam photons way out of time with Beam__IsGenerator==1, see plot below. As I dug into the code that determines this quantity here<https://urldefense.proofpoint.com/v2/url?u=https-3A__nam10.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldefense.proofpoint.com-252Fv2-252Furl-253Fu-253Dhttps-2D3A-5F-5Fnam10.safelinks.protection.outlook.com-5F-2D3Furl-2D3Dhttps-2D253A-2D252F-2D252Furldefense.proofpoint.com-2D252Fv2-2D252Furl-2D253Fu-2D253Dhttps-2D2D3A-2D5F-2D5Fnam10.safelinks.protection.outlook.com-2D5F-2D2D3Furl-2D2D3Dhttps-2D2D253A-2D2D252F-2D2D252Fgithub.com-2D2D252FJeffersonLab-2D2D252Fhalld-2D2D5Frecon-2D2D252Fblob-2D2D252F2c9a71a53e6ca9285be0d0d7e8a7afc9bd19e57c-2D2D252Fsrc-2D2D252Flibraries-2D2D252FPID-2D2D252FDBeamPhoton-2D2D5Ffactory-2D2D5FTAGGEDMCGEN.cc-2D2D2523L44-2D2D26data-2D2D3D04-2D2D257C01-2D2D257C-2D2D257C9a49d0c045724e468cb408d93343dee2-2D2D257C17f1a87e2a254eaab9df9d439034b080-2D2D257C0-2D2D257C0-2D2D257C637597188870551297-2D2D257CUnknown-2D2D257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-2D2D253D-2D2D257C1000-2D2D26sdata-2D2D3DW3JcyFlP1ix-2D2D252BATsXch-2D2D252BRAMBCKA3kEECv29wJcBK5vbw-2D2D253D-2D2D26reserved-2D2D3D0-2D2526d-2D253DDwMFaQ-2D2526c-2D253DCJqEzB1piLOyyvZjb8YUQw-2D2526r-2D253DmWHgh9kgeTdfLG7caifCQnkq64mj-2D2DZ8j5T6ci0QKA-2D2Dw-2D2526m-2D253Du2igqaZZ6udRe1TPoaIyY0TMgiebmCuVHNC5OiwE1jw-2D2526s-2D253DagjDR5yuSNy83InFDKryQSdFTYkIMV9-2D5FTNQQ-2D5FnazZTk-2D2526e-2D253D-2D26data-2D3D04-2D257C01-2D257C-2D257C4054a828929b429041f208d934f15e89-2D257C17f1a87e2a254eaab9df9d439034b080-2D257C0-2D257C0-2D257C637599033547339140-2D257CUnknown-2D257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-2D253D-2D257C1000-2D26sdata-2D3DfRsDyzNnhrOxYhFLcTeA-2D252FTZd8JXMa0wUpiv3-2D252Bd4-2D252F00Y-2D253D-2D26reserved-2D3D0-2526d-253DDwMFaQ-2526c-253DCJqEzB1piLOyyvZjb8YUQw-2526r-253DmWHgh9kgeTdfLG7caifCQnkq64mj-2DZ8j5T6ci0QKA-2Dw-2526m-253D6MeCUMcWNvk-2DJvKgGqYI5bZKSV3RW3lyspsY0XfdVFI-2526s-253DpiNHWqqf5zPqpQReLZTyiLanYVjfRmWWX1HtvifREeU-2526e-253D-26data-3D04-257C01-257C-257Caad0a1786dd84cfedd4f08d934f728bb-257C17f1a87e2a254eaab9df9d439034b080-257C0-257C0-257C637599058427831949-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C1000-26sdata-3DFQX4ug8ZimTuAlPSF59WfXnEyw2ZeXJVCAKyQjSUtN4-253D-26reserved-3D0&d=DwMFaQ&c=CJqEzB1piLOyyvZjb8YUQw&r=mWHgh9kgeTdfLG7caifCQnkq64mj-Z8j5T6ci0QKA-w&m=zdr6DX9pZAPq2llrU2gKCsEbiO0Kfhd0BviK969AC0I&s=0tGp2z3XvW4MG6NEFfgpWgGDlrQfGnYRDA4OPp-lprk&e=> I see that it appears to accept any tagger hit that happens to light up the correct counter number (ultimately, it selects the best Delta t timing). So I think if the true beam photon was not seen, but some accidental happened to hit the correct counter, it would get set to Beam__IsGenerator==1. This appears to be about a 1% effect in some eta MC.

For context, I'm thinking about event counting / uniqueness tracking. I was trying to verify that accidental subtraction works properly in MC by comparing accidental subtracted counts to number of true beam photons. Right now they're not agreeing, by about 1% or so like I said.

Any thoughts?

Cheers,
Jon

[cid:17a307b41d6cddb20da1]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.jlab.org/pipermail/halld-unique/attachments/20210701/85513b90/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Outlook-24l1tm32.png
Type: image/png
Size: 39706 bytes
Desc: Outlook-24l1tm32.png
URL: <https://mailman.jlab.org/pipermail/halld-unique/attachments/20210701/85513b90/attachment-0001.png>