Unexpected Charged RF Bunch behavior with missing TOF hits in simulation

[jrstevenjlab]

This follows up on the issue of missing signal TOF hits in simulation discussed here https://github.com/JeffersonLab/halld_sim/issues/279. From a halld_recon perspective, we would naively expect that if we use events with the correct signal TOF hits in the simulation, we would have a higher efficiency for reconstructing all charged particle final states. However, @imoewi01 found that was not the case for some of his omegapipi samples https://halldweb.jlab.org/doc-private/DocDB/ShowDocument?docid=6330

I did a little digging into the particle combo construction for two runs in the omega pi+ pi- sample from a good run 51768 (with all TOF MC hits) and from a bad run 51767 (missing all TOF MC hits), see histograms and macro at /work/halld2/home/jrsteven/forWill/1.23.24/

In the left of the figure the events passing different combo creation cuts is shown for the run with good TOF hits (black) and missing TOF hits (red). You can see that initially there are 10% more events with a particle combo in the events with good TOF hits, which matches the expectation of higher reconstruction efficiency. However, at the step where the charged track combo is matched to the RF bunch the run with good TOF hits (black) loses many more events than the one with missing TOF hits (red), and this difference seems to carry through the rest of the combo creation and event selection. The ratio of black/red is shown on the right side. So for some reason the creation of the "Charged RF Bunch" is less efficient when we have good TOF hits in MC which leads to the lower efficiency we observe when excluding runs with missing TOF hits. The place where this is done in our ANALYSIS library is in the DSourceComboer

https://github.com/JeffersonLab/halld_recon/blob/master/src/libraries/ANALYSIS/DSourceComboer.cc#L1659

While it's counterintuitive, I think this confirms your lower efficiency for these high-multiplicity charged pion reactions when excluding files with missing TOF hits is correct (despite the higher individual track reconstruction efficiency).

Some thoughts/conclusions:

1) There can be subtle issues in ANALYSIS library when a detector like the TOF hits are missing in simulation. So for MC samples that are affected by this issue https://github.com/JeffersonLab/halld_sim/issues/279, we need to either remove all the files that are missing TOF hits or generate new MC

2) The "Charged RF Bunch" efficiency being unexpectedly reduced when we have good TOF hits in the MC could be pointing to a deeper issue in the ANALYSIS library. Potentially relevant for other analyses, this step can be different for a reaction with mostly neutral particles compared to one with a high multiplicity of charged particles, e.g. gp -> eta p, with eta -> gg compared to eta -> pi+pi-pi0. So this could be a place where we need to look for our discrepancy between "charged" and "neutral" decay modes

[sdobbs]

Thanks for digging into this, Justin. Can we make two sets of simulations with the same software and same events, just differing in if the TOF hits are used or thrown away? That would help in digging into these ANALYSIS library issues.

[jrstevenjlab]

Yes, we can do that for a small sample of events in a couple reactions of interest to address 2) which will likely require more time for a deeper dive.

For 1) I think we should be clear that old simulations with this issue are not good enough for publication unless the files missing TOF hits are removed or its otherwise demonstrated this doesn't impact a particular analysis. In other words, there's no reason to delay starting new simulations now.

[sdobbs]

Yes, I 100% agree - we'll need to look more into this, but simulations with this bug should not be used.

[jrstevenjlab]

As requested, I made two sets of eta' simulations with the same software (recon-2018_08-ver02_28.xml) and same events (1M events from the same generator HDDM file). One set was treated normally and the other the TOF hits from signal MC were discarded by using the flag -lBCAL,FCAL,ST,CDC,FDC,RF,TAGH,TAGH in mcsmear. With Will we agreed to look at the 3 decays of the eta' that he's been studying:

eta' -> eta pi+ pi-, eta -> pi+pi-pi0: ETAP_ETAPIPI_3PI_2018_08_ver02_28 eta' -> eta pi+ pi-, eta -> pi0pi0pi0: ETAP_ETAPIPI_3PI0_2018_08_ver02_28 eta' -> eta pi0 pi0, eta -> pi+pi-pi0: ETAP_ETAPI0PI0_3PI_2018_08_ver02_28

The files for these samples can be found at /work/halld/home/jrsteven/simulation/ and contain all the usual ROOT files as well as the REST and smeared HDGEANT4 output files, so we can analyze the simulated events with modifications to the ANALYSIS library.

To start things off I made the same plots of event reduction for the 3 samples, same colors as before: good TOF hits (black) and missing TOF hits (red). All 3 channels show an increased efficiency in the first few bins up to "Charged Combos", but the efficiency is lower for the samples with TOF hits after the "Charged RF Bunch" step. The effect is bigger for decay mode with 4 charged pions than the other decay modes with only 2 charged pions.

c2.pdf

[aaust]

I tried to match the events to figure out what exactly is changing, but it looks like there are already differences in the generated info. While the 4-momenta of the outgoing particles are exactly the same, the timing for the primary vertex is different for both samples. Here is one example for the first channel. no_tof:

<reconstructedPhysicsEvent eventNo="4" runNo="51768">
    <reaction Ebeam="7.93388" Eunit="GeV" jtag="" targetType="Proton(14)" type="0" weight="0">
      <vertex>
        <origin lunit="cm" t="-8.01603" vx="0" vy="0" vz="65" />
        <product id="1" parentId="0" pdgtype="211">
          <momentum E="0.644499" Eunit="GeV" punit="GeV/c" px="-0.10997" py="0.000482" pz="0.61952" />
        </product>

default:

  <reconstructedPhysicsEvent eventNo="4" runNo="51768">
    <reaction Ebeam="7.93388" Eunit="GeV" jtag="" targetType="Proton(14)" type="0" weight="0">
      <vertex>
        <origin lunit="cm" t="4.00802" vx="0" vy="0" vz="65" />
        <product id="1" parentId="0" pdgtype="211">
          <momentum E="0.644499" Eunit="GeV" punit="GeV/c" px="-0.10997" py="0.000482" pz="0.61952" />
        </product>

This makes comparison on an event-by-event level difficult. If both events come from the same generator file, there must be some level of randomness in the simulation of the vertex in geant.

[jrstevenjlab]

Ah right, I think there is a step in hdgeant4 that randomizes the vertex time and position within the target. It would have been better to just separately run mcsmear over the output of the regular simulation with the TOF flag removed. Sorry, I will do that for the first file in each sample, so we can at least compare them event-by-event.

[rjones30]

Hello all,

If you want to simulate the exact same event under different beam or detector conditions, you can take the output from one hdgeant4 pass and feed it back in for subsequent analysis passes. That way, you get the same vertex position assigned to each event in subsequent simulations. The hitView tag should be removed before cycling an output hddm file back as input. A few lines of python will accomplish this, write to me if you need an example.

-Richard Jones

On Wed, Feb 7, 2024 at 2:10 PM Justin Stevens @.***> wrote:

Ah right, I think there is a step in hdgeant4 that randomizes the vertex time and position within the target. It would have been better to just separately run mcsmear over the output of the regular simulation with the TOF flag removed. Sorry, I will do that for the first file in each sample, so we can at least compare them event-by-event.

— Reply to this email directly, view it on GitHub https://github.com/JeffersonLab/halld_recon/issues/780#issuecomment-1932698129, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB3YKWC4TCDB4372F2YR5NDYSPGSVAVCNFSM6AAAAABCKV6OTWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZSGY4TQMJSHE . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[jrstevenjlab]

For testing the difference with and without simulated TOF hits for these channels there are now 10k events in a single file at this path /work/halld/home/jrsteven/simulation/singleFile/ for the 3 channels

eta' -> eta pi+ pi-, eta -> pi+pi-pi0: ETAP_ETAPIPI_3PI_2018_08_ver02_28_single eta' -> eta pi+ pi-, eta -> pi0pi0pi0: ETAP_ETAPIPI_3PI0_2018_08_ver02_28_single eta' -> eta pi0 pi0, eta -> pi+pi-pi0: ETAP_ETAPI0PI0_3PI_2018_08_ver02_28_single

For each channel there is a noTOF directory within where I smeared the exact same hdgeant4 output to make a new REST file and monitoring histograms. These can be compared directly event-by-event to have the exact same events with and without simulated TOF hits.

For example, compare with TOF: /work/halld/home/jrsteven/simulation/singleFile/ETAP_ETAPIPI_3PI_2018_08_ver02_28_single/hddm/etap_checks_051768_000_geant4_smeared.hddm

and without TOF: /work/halld/home/jrsteven/simulation/singleFile/ETAP_ETAPIPI_3PI_2018_08_ver02_28_single/noTOF/hddm/etap_checks_noTOF_051768_000_geant4_smeared.hddm

[aaust]

Thanks, I looked at a few individual events and how they differ in the two samples. During the "Charged RF Bunch" step, all charged tracks have to agree on the same RF bunch within their individual timing resolutions. When a charged track is matched to the TOF, the timing resolution is set to 0.5ns which eliminates many combos/events. Without the TOF on the other hand, a much broader timing window of 2ns is used instead, which corresponds to the resolution of the FCal. As a result, more combos/events survive. At this point, it is difficult to judge if the additional combos/events are meaningful and have an impact on the extracted cross section. Since the timing resolution can be easily changed on the command line, we propose to measure the cross section for high-statistics channels (rho, omega) for various settings (0.5ns, 1ns, 1.5ns, 2ns). Here are the relevant options:

COMBO_TIMECUT:9_8 1     //Cut pi+ (9) in the TOF (8) at +/- 1ns
COMBO_TIMECUT:8_8 1     //Cut pi- (8) in the TOF (8) at +/- 1ns
COMBO_TIMECUT:14_8 1     //Cut proton (14) in the TOF (8) at +/- 1ns

It has to be noted that the same values are used again later in the analysis library to determine the PID via deltaT.

[jrstevenjlab]

Thanks for digging in to this @aaust. As we discussed, running a quick analysis launch with these different resolutions should allow us to check the cross sections, to see if there's any data/MC difference in this effect of the timing cut in the RF selection stage. So I would suggest we produce trees for 3 reactions for a run from the Fall 2018 data, 51768 since we already have some MC from that run already

pippimB4 pi0pippimB4 gg__B4

This should be enough to compare exclusive reactions with fully charged (rho), fully neutral (pi0) and charged+neutral (omega) between these 4 settings and see what the impact is. Could you produce the data with these options and report here the halld_recon version used and JANA config file, so we can use the same options for the MC?

[aaust]

We ran the ReactionFilter for the three reactions mentioned above with version_5.15.0.xml on run 51768. You may find the trees here: /volatile/halld/home/aaustreg/RF_Bunch/

For the rho, we see about a 5% increase in yields by opening the cut from 0.5ns (default) to 1.0ns, with a slight energy dependence. Further widening has a much smaller effect.

We are waiting for the MC sample for acceptance correction to be able to draw any conclusions.

[aaust]

It seems, the MC acceptance correction slightly over-corrects this effect, which results in a smaller absolute cross section for the rho by 3-8% depending on the cut value:

[imoewi01]

Alex's result is consistent with an initial study I did for the omega cross section. Looking at the default TOF timing cut vs widening the cut to +/-2 ns, I find the wider cut has a 7-9% smaller cross section than the default timing cut.

[curtisameyer]

That is interesting as it appears to be a constant offset. I also would have expected this to go the other way. It does not appear consistent with the no TOF result, but we probably do not know enough yet.Curtis____Curtis A. Meyer Interim Dean, Mellon College of ScienceThe Otto Stern Professor of PhysicsProfessor by Courtesy, Pittsburgh Supercomputing CenterCarnegie Mellon University, Pittsburgh PA @.  |  (412) 260-6290   www.curtismeyer.comOn Feb 26, 2024, at 7:42 PM, William Imoehl @.> wrote: Alex's result is consistent with an initial study I did for the omega cross section. Looking at the default TOF timing cut vs widening the cut to +/-2 ns, I find the wider cut has a 7-9% smaller cross section than the default timing cut. xs_vs_beamEn.pdf

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>

[imoewi01]

A quick follow up on the omega study - I now use all four TOF timing cut variations, and use the same color scheme as Alex. The size of the discrepancy seems consistent between our results: around 2.5% for a TOF timing cut of +/-1.0 ns around 5.5% for a TOF timing cut of +/-1.5 ns around 7.5% for a TOF timing cut of +/-2.0 ns

[sdobbs]

Thanks for all of the studies here - has anyone pulled out a comparison of the combo creation histograms like Justin showed in the original post?

[jonzarling]

I did a similar study to what Alex did for the eta (using the same data files that he generated and same analysis config for my MC samples). In short, I see a similar ~ 5% effect with the widest cut value. Interestingly, my results seem consistent between a 0.5 and 1.0 ns cut on the TOF.

As one would expect, the cut value has essentially no impact on the eta->gamma gamma and the eta->3pi0 decay modes, the yields are basically the same for all cut values.

For the eta->pi+pi-pi0 the statistics in a single data file are fairly low but I was able to look over a wide range of beam energy. Here is what a cross section from 7-11.5 GeV in beam energy and 0.1< |t| < 0.5 GeV^2 for Mandelstam t.

[jonzarling]

There's one more flag that we could consider studying: PRESELECT:HAS_DETECTOR_MATCH_FLAG 0. Would that be worth trying to toggle as well?

[sdobbs]

Some rambling thoughts:

I looked in some detail at some of these MC events, and it seems like a noticeable contribution to the events at this RF bunch selection stage are from tracks that are not well reconstructed. This stage both tries to determine a common RF bunch for all of the tracks in a combo, and applies some "loose" timing selections based on the detector time propagated to the reconstructed track vertex, in order to reduce the combinatorics. So among other dependencies, this procedure relies on how well the charged particles are reconstructed, and modeling well this procedure in simulation. The results above seem to point to the idea that this rate is different in data and simulation.

In the typical case that we rely on the kinematic fit, we can likely live with a track or two (depending on the topology) not being well reconstructed, since the fit will tend to correct the parameters of the poorly measured tracks. Note that the "loose" timing cuts are applied again at the end of this procedure.

So, this effect sounds like is backs up the observed effect that the efficiency changes in one direction as the cuts are loosened (unsurprising), and the suggested idea to use looser cuts for the analysis launch, with tighter timing cuts applied at the DSelector stage (which should reproduce the behavior of applying looser timing cuts pre-kinematic fit, with tighter cuts post-kinematic fit). Note that we do want to apply cuts similar to the default ones at least at the post-kinematic fit level, to reduce additional combos from mis-ID'd particles at lower momentum.

Another test that could be done is to keep on loosening the timing cuts and see at what point the "Charged RF bunch" efficiency plateaus.

Note that tracks with detached vertices might not be affected that much, since a looser cut is applied on the tracks from the detached vertex at this point, since we don't know the location of the secondary vertex well.

[sdobbs]

As a quick follow up, here is a look at the combo efficiencies of some looser TOF and BCAL cuts for the file /work/halld/home/jrsteven/simulation/singleFile/ETAP_ETAPIPI_3PI_2018_08_ver02_28_single/hddm/dana_rest_etap_checks_051768_000.hddm

It looks like one should look at the final efficiencies after the standard time cuts have been applied at analysis time for these variations, and see what those show.

[jrstevenjlab]

At some point when we widen the timing cuts, do we start including accidental beam photons from out of time bunches?

The big jump from 6 -> 8 ns wide cut for the BCAL DeltaT is also pretty shocking, why does it turn on so sharply there?

[sdobbs]

That would be my guess, that we are getting additional combos from the inclusion of additional beam bunches, in addition to the lack of PID discrimination. Looking at most of the standard plots didn't give much insight into the reason for the difference, though if you look at the number of combos that survived each of these steps, it looks like it's mostly being driven by the number of beam bunches allowed. In this plot, the solid line is the Delta T (BCAL) > 8 ns selection and the dashed is the default (don't know why the number of charged combos is larger!):

In any case, this could be another reason why it's better to compare these samples once the usual PID cuts have been applied post kinematic fit, since those should reject most of the spurious combos.

[aaust]

I repeated the study with a cut on the TOF PID timing in the DSelector. This cut is applied to all particles in the final state, both on measured and fitted quantities, similar to what is done in the analysis library. This is the analysis action code:

dAnalysisActions.push_back(new DCutAction_PIDDeltaT(dComboWrapper, false, 0.5, PiPlus, SYS_TOF));
dAnalysisActions.push_back(new DCutAction_PIDDeltaT(dComboWrapper, false, 0.5, PiMinus, SYS_TOF));
dAnalysisActions.push_back(new DCutAction_PIDDeltaT(dComboWrapper, false, 0.5, Proton, SYS_TOF));
dAnalysisActions.push_back(new DCutAction_PIDDeltaT(dComboWrapper, true, 0.5, PiPlus, SYS_TOF, "kf"));
dAnalysisActions.push_back(new DCutAction_PIDDeltaT(dComboWrapper, true, 0.5, PiMinus, SYS_TOF, "kf"));
dAnalysisActions.push_back(new DCutAction_PIDDeltaT(dComboWrapper, true, 0.5, Proton, SYS_TOF, "kf"));

With this cut, the cross sections for all samples come out identically, without any dependence on the TOF timing cut value:

[sdobbs]

Thanks @aaust - I wonder what happens if you just cut on the kin fit times, not the measured times.

[jrstevenjlab]

Following up on @aaust's latest plots, as @sdobbs said the cut on the measured quantities in the DSelector should behave like the analysis library cut at the Charged RF Bunch stage (before the KinFit). So I think we would expect to reproduce the results of the default analysis library cut of 0.5 ns cut when that same cut is applied to both the measured and KinFit time PIDDeltaT in the DSelector. If we just make a cut on the KinFit PIDDeltaT in the DSelector it would emulate the proposal of having a wider cut in the analysis library before the KinFit is performed and then applying a tighter cut on the KinFit track with better extrapolation to the vertex.

To summarize the discussion at the XWG meeting on Monday: we agreed to study the effects of the cuts on the time difference using the measured and KinFit track extrapolations as Sean pointed out in this thread. The idea was to find a set of looser cuts that can become the new defaults in the Analysis library where the efficiency in MC is stable. This can be done in 2 ways:

1. You can use analysis trees with varied values of the timing cuts applied in the analysis library and make the same tight cut on the KinFit PIDDeltaT in the DSelector to see how the cross section changes with the cut in the analysis library (i.e. what we're suggesting for Alex above)
2. You can use the same analysis tree with a wide timing cut (or no timing cut at all) in the analysis library and then apply varying cuts on the measured PIDDeltaT in the DSelector to emulate the cut using measured quantities in the analysis library Charged RF Bunch stage

[aaust]

@sdobbs @jrstevenjlab Even when I only cut on the TOF PID timing of the kinfit quantities (only the lines with true in the code snippet above), I get almost exactly the same yields and ratios as if I cut on both measured and kinfit. What is maybe more relevant, I get exactly the same cross section with the default analysis library as with the 2ns trees when applying the 0.5ns in the DSelector.

[jrstevenjlab]

We'll have a broader discussion about this at the Open Analysis meeting today, but I'll add a few plots to get people thinking. Since @aaust found there wasn't a significant change when making a cut on the TOF DeltaT using the Kinematic Fit compared to the Measured quantities, I made plots of these TOF DeltaT distributions in Data and MC for the pi+ and pi- tracks from omega -> pi+pi-pi0 events

DeltaT_TOF.pdf

There are a couple interesting features in these plots:

• A long tail in the MC that extends to much larger values of positive DeltaT than the Data
• A peak at -4 ns in MC and -3 ns in Data for both the KinFit and Measured distributions

This long tail appears to be the source of the changing efficiency in the MC with widening the DeltaT cut. This can be seen in the plot below which shows the pi+pi-pi0 mass distribution from omega MC for varying cuts on the TOF and BCAL DeltaT cut on charged pions. The yield of omegas doesn't saturate until the TOF cut is widened to 6 or 8 ns, consistent with the long tail observed in the MC

mass3pi_DeltaTcuts.pdf

As for the peak at negative DeltaT, I originally thought it was due to out of time beam photons. However, I generated a sample of omega MC events without any random triggers, so there is no out of time beam photons and the peak at -4 ns is still present in the distribution (see plot below). Also, the peak in the data is at -3 ns which points to a different source for this structure that may be a hint for what's wrong with the TOF timing in MC.

DeltaT_TOF_noRandom.pdf

Short summary: the TOF timing distribution in MC doesn't appear to match data and this seems to be the source of loss of events at this "Charged RF Bunch" stage of the ANALYSIS libraries selection of particle combinations.

[sdobbs]

Thanks Justin, this is pretty interesting. It will be helpful to compare the different components that go into the Delta T calculation, to see where the differences come from. Could you share which simulations you are looking at here?

[jrstevenjlab]

@sdobbs, yes I made 3 versions of the omega -> pi+pi-pi0 files

Nominal configuration: /volatile/halld/home/jrsteven/simulation/omega_2018_08_ver02_28_single_fullE/

No random trigger background: /volatile/halld/home/jrsteven/simulation/omega_noRandom_2018_08_ver02_28_single_fullE/

No TOF hits in simulation (achieved by rejecting in mcsmear): /volatile/halld/home/jrsteven/simulation/omega_noTOF_2018_08_ver02_28_single_fullE/

The last version without TOF hits was meant to look at the FCAL timing distributions. Since it's at the same location as the TOF it should have similar effects from the track length component of the DeltaT calculation. Below is the plot of the FCAL DeltaT when there are no TOF hits in the simulation and you can see the tail appears to be less significant and there is no peaking structure for negative DeltaT values

DeltaT_FCAL.pdf

So this seems to be pointing to TOF simulation as the issue, which I'm trying to look at now to see if there are specific kinds of TOF points that are problematic: e.g. single-ended hits, half-length paddles, narrower bars, etc.

[sdobbs]

@jrstevenjlab - Thanks, yeah that is interesting about the FCAL timing.

One thing I noticed flipping through the monitoring lists is that the TOFPointEnergy has a three-peaked structure, which we didn't have in earlier simulations, which could certainly point towards specific categories of hits being the problem.

[sdobbs]

Thanks to @jrstevenjlab for making some simulations including the hit-level information. These files also include more truth information, so below I compare the reconstructed and truth TOF point times for reconstructed TOF points which have double-ended hits on both paddles, and we can see the clear tail to higher times (recon. - truth time). Looking at 10k events doesn't seem to show a particular preference for where this happens on the TOF.

To try to get a better feeling for where this might be happening, I picked out one event with a recon.-truth time difference was around 3 ns (event 43 of /volatile/halld/home/jrsteven/simulation/omega_noRandom_smeared_2018_08_ver02_28_single_fullE/hddm/gen_omega_3pi_tof_checks_051768_010_geant4.hddm), and dumped some details of the particular hit:

DTOFHit:
 bar: plane: end:           dE:          Amp:            t:        t_TDC:       t_fADC:
---------------------------------------------------------------------------------------
  24      0    0        0.0067        0.0000       37.7123       37.7123       37.7123 
  24      0    0        0.0003        0.0000      186.7806      186.7806      186.7806 
  24      0    0        0.0000        0.0000      379.4003      379.4003      379.4003 
  24      0    0        0.0000        0.0000      408.9789      408.9789      408.9789 
  24      0    0        0.0000        0.0000      465.2751      465.2751      465.2751 
  24      0    0        0.0000        0.0000      506.1112      506.1112      506.1112 
  24      0    0        0.0000        0.0000      731.1373      731.1373      731.1373 
  24      0    1        0.0036        0.0000       44.5233       44.5233       44.5233 
  24      0    1        0.0002        0.0000      189.7975      189.7975      189.7975 
  24      0    1        0.0000        0.0000      411.2976      411.2976      411.2976 
  24      0    1        0.0000        0.0000      438.5957      438.5957      438.5957 
  24      0    1        0.0000        0.0000      467.4305      467.4305      467.4305 
  24      0    1        0.0000        0.0000      508.4612      508.4612      508.4612 
  24      0    1        0.0000        0.0000      733.2239      733.2239      733.2239 
  31      1    0        0.0069        0.0000       42.1000       42.1000       42.1000 
  31      1    0        0.0001        0.0000       71.4371       71.4371       71.4371 
  31      1    1        0.0055        0.0000       43.1135       43.1135       43.1135 
  31      1    1        0.0001        0.0000       78.1477       78.1477       78.1477 

DTOFHit:TRUTH
 bar: plane: end:           dE:          Amp:            t:        t_TDC:       t_fADC:
---------------------------------------------------------------------------------------
  24      0    0        0.0029        0.0000       37.7912       37.7912       37.7912 
  24      0    0        0.0001        0.0000      186.9525      186.9525      186.9525 
  24      0    0        0.0000        0.0000      379.6310      379.6310      379.6310 
  24      0    0        0.0000          -nan      409.0661      409.0661      409.0661 
  24      0    0        0.0000       -0.0000      436.4194      436.4194      436.4194 
  24      0    0        0.0000       -0.0000      465.2012      465.2012      465.2012 
  24      0    0        0.0000        0.0000      506.1289      506.1289      506.1289 
  24      0    0        0.0000        0.0000      731.0568      731.0568      731.0568 
  24      0    1        0.0015          -nan       44.4993       44.4993       44.4993 
  24      0    1        0.0001          -nan      189.5572      189.5572      189.5572 
  24      0    1        0.0000       -0.0000      381.8770      381.8770      381.8770 
  24      0    1        0.0000       -0.0000      411.2506      411.2506      411.2506 
  24      0    1        0.0000        0.0000      438.6202      438.6202      438.6202 
  24      0    1        0.0000        0.0000      467.4399      467.4399      467.4399 
  24      0    1        0.0000          -nan      508.3611      508.3611      508.3611 
  24      0    1        0.0000       -0.0000      733.2957      733.2957      733.2957 
  31      1    0        0.0030          -nan       42.0591       42.0591       42.0591 
  31      1    0        0.0001       -0.0000       71.4376       71.4376       71.4376 
  31      1    1        0.0024        0.0000       42.9445       42.9445       42.9445 
  31      1    1        0.0000        0.0000       78.0632       78.0632       78.0632 

DTOFHitMC:
 bar: plane: end:         dist:            x:            y:            z:           px:           py:           pz:            E: ptype: itrack:
------------------------------------------------------------------------------------------------------------------------------------------------
  24      0    0    4.8816e+01    7.3087e+00    4.8816e+01    6.0960e+02    2.4787e-02    1.5376e-01    1.7961e+00    1.8083e+00      9       3 
  24      0    0    2.0201e+01    9.2247e+00    2.0201e+01    6.1067e+02   -1.1870e-02    9.2108e-03   -1.4280e-02    9.3979e-01     13      -2 
  24      0    0    1.6845e+01    6.8456e+00    1.6845e+01    6.1023e+02    4.4064e-04   -5.1482e-04    4.1132e-05    9.3957e-01     13      -2 
  24      0    0    1.6413e+01    7.2165e+00    1.6413e+01    6.1026e+02    4.5358e-04   -5.0365e-04    7.1434e-06    9.3957e-01     13      -2 
  24      0    0    1.6506e+01    7.4863e+00    1.6506e+01    6.1007e+02    2.0019e-04    3.3855e-04   -3.8682e-04    9.3957e-01     13      -2 
  24      0    0    1.6792e+01    7.6668e+00    1.6792e+01    6.0976e+02    2.6423e-04    3.4919e-04   -3.2290e-04    9.3957e-01     13      -2 
  24      0    0    1.6741e+01    7.8627e+00    1.6741e+01    6.0958e+02    8.1599e-05   -1.0218e-04    2.3405e-05    9.3957e-01     13      -2 
  24      0    0    1.6791e+01    8.1431e+00    1.6791e+01    6.0978e+02    3.6737e-05    1.2931e-05    2.8617e-05    9.3957e-01     13      -2 
  24      0    1    4.8816e+01    7.3087e+00    4.8816e+01    6.0960e+02    2.4787e-02    1.5376e-01    1.7961e+00    1.8083e+00      9       3 
  24      0    1    2.0201e+01    9.2247e+00    2.0201e+01    6.1067e+02   -1.1870e-02    9.2108e-03   -1.4280e-02    9.3979e-01     13      -2 
  24      0    1    1.6845e+01    6.8456e+00    1.6845e+01    6.1023e+02    4.4064e-04   -5.1482e-04    4.1132e-05    9.3957e-01     13      -2 
  24      0    1    1.6413e+01    7.2165e+00    1.6413e+01    6.1026e+02    4.5358e-04   -5.0365e-04    7.1434e-06    9.3957e-01     13      -2 
  24      0    1    1.6506e+01    7.4863e+00    1.6506e+01    6.1007e+02    2.0019e-04    3.3855e-04   -3.8682e-04    9.3957e-01     13      -2 
  24      0    1    1.6792e+01    7.6668e+00    1.6792e+01    6.0976e+02    2.6423e-04    3.4919e-04   -3.2290e-04    9.3957e-01     13      -2 
  24      0    1    1.6741e+01    7.8627e+00    1.6741e+01    6.0958e+02    8.1599e-05   -1.0218e-04    2.3405e-05    9.3957e-01     13      -2 
  24      0    1    1.6791e+01    8.1431e+00    1.6791e+01    6.0978e+02    3.6737e-05    1.2931e-05    2.8617e-05    9.3957e-01     13      -2 
  31      1    0    7.2743e+00    7.2743e+00    4.8597e+01    6.0702e+02    2.3256e-02    1.5254e-01    1.8008e+00    1.8128e+00      9       3 
  31      1    0    4.9904e+01    4.9904e+01    4.4648e+01    6.0810e+02   -3.3857e-03    7.2250e-03   -1.2490e-02    9.3968e-01     13      -2 
  31      1    1    7.2743e+00    7.2743e+00    4.8597e+01    6.0702e+02    2.3256e-02    1.5254e-01    1.8008e+00    1.8128e+00      9       3 
  31      1    1    4.9904e+01    4.9904e+01    4.4648e+01    6.0810e+02   -3.3857e-03    7.2250e-03   -1.2490e-02    9.3968e-01     13      -2 

DTOFPaddleHit:
 orientation: bar: t_north: E_north: t_south: E_south: meantime: timediff:    pos:  dpos:    dE:
------------------------------------------------------------------------------------------------
           0   24   37.712    0.007   44.523    0.004    32.718     3.405  51.082  2.000  0.005 
           1   31   42.100    0.007   43.114    0.006    34.207     0.507   7.602  2.000  0.006 

DTOFPoint:
 H-Bar: V-Bar:      x:      y:       z:      t:       dE:      dE1:      dE2: H-Status: V-Status:
-------------------------------------------------------------------------------------------------
    31     24   7.602  51.082  608.353  33.462  0.005637  0.005089  0.006184         3         3 

DTOFTruth:
 track: itrack: primary: ptype:      x:      y:       z:      t:    px:    py:    pz:     E:
--------------------------------------------------------------------------------------------
     3       3        1      9   7.309  48.816  609.601  30.323  0.025  0.154  1.796  1.808 

You can see a lot of extra hits on the bar from some sort of secondary interaction which are discarded, but besides that, at first look the reconstruction looks reasonable, which I think points to some issue in how the hit times are being generated in hdgeant4.

[sdobbs]

Thanks again to @jrstevenjlab for making some simulations where we disable the hit merging. The timing tails are much smaller. We are going to try to make a change to hdgeant4 to use the time of the first hit, but merge the energies, which is the strategy followed in the Start Counter, for example.

Difference between reconstructed and truth TOF Point times (no hit merging)

Usual Delta T distribution used in analysis (no hit merging)

[curtisameyer]

This is encouraging --

---

Curtis A. Meyer | Interim Dean, Mellon College of Science The Otto Stern Professor of Physics Professor by Courtesy, Pittsburgh Supercomputing Center @.*** | 412 260 6290 Carnegie Mellon University Mellon College of Science 4400 Fifth Avenue Pittsburgh, PA 15213 www.curtismeyer.com

Please do not feel compelled to reply outside of normal working hours.

On Mar 20, 2024, at 10:56, Sean Dobbs @.***> wrote:

Thanks again to @jrstevenjlab https://github.com/jrstevenjlab for making some simulations where we disable the hit merging. The timing tails are much smaller. We are going to try to make a change to hdgeant4 to use the time of the first hit, but merge the energies, which is the strategy followed in the Start Counter, for example.

Difference between reconstructed and truth TOF Point times (no hit merging) tof_notail.png (view on web) https://github.com/JeffersonLab/halld_recon/assets/1182058/faccddc0-8584-442d-b4af-46621a642bc3 Usual Delta T distribution used in analysis (no hit merging) tof_deltat_notail.png (view on web) https://github.com/JeffersonLab/halld_recon/assets/1182058/8f4838ac-7337-4edf-9e34-117a09c0982f — Reply to this email directly, view it on GitHub https://github.com/JeffersonLab/halld_recon/issues/780#issuecomment-2009770062, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADB5P5UH7W6GECAYJ4X6D73YZGPQRAVCNFSM6AAAAABCKV6OTWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMBZG43TAMBWGI. You are receiving this because you commented.

[sdobbs]

Something else fun that I noticed, that if I look at various classes of TOF points matched to tracks, there is one class where there is one single-ended hit in one plane, and no corresponding hit in another plane - basically TOF points made of only one hit. The Delta T distribution looks like this:

So this seems to be the major (only?) contributor to the negative side peak. It is maybe not too surprising, since the position of the point is not too well defined.

However, if I use the most recent reconstruction code, these "single hit points" don't show up anymore - so we probably did something reasonable, but some archaeology must be performed to figure out what. At least, it seems reasonable to keep on rejecting such events, if their efficiency is well modeled.

[sdobbs]

For completeness, I am also linking to the meeting page for Tuesday's analysis meeting, where additional slides are linked to.

[jrstevenjlab]

The issue with the long tail in the TOF hit DeltaT was due to merging of hits with late arrival times using an energy-weighted average of the time for a hit in one paddle. A simple fix was applied to use the time of the first hit that arrives to approximate the leading edge time measured by the electronics IRL. See the PR on hdgeant4 for more details https://github.com/JeffersonLab/HDGeant4/pull/219

Applying this fix and generating a new sample of omega -> pi+pi-pi0 MC we can see that the timing distribution now agrees quite well between data and MC with the long tail now being removed from

DeltaT_TOF_first_hit.pdf

A zoomed in version from +/- 1 ns of the same plot shows that there may still be some lingering difference in the resolution between data and MC that we could consider tuning in mcsmear

DeltaT_TOF_first_hit_zoom.pdf

Finally, with the new MC sample I was able to redo the comparison of the omega radiative and charged decay modes to plot the ratio of branching ratios. The mass spectra of gamma pi0 and pi+pi-pi0 are attached here for MC (left) and data (right)

omegaMass_first_hit.pdf

Finally the ratio of branch ratios is below plotted vs the DeltaT cut applied to the TOF in the ANALYSIS library. The result is consistent with the upper error bar of the PDG value (red lines) and equally important is consistent vs the DeltaT cut that is used

omegaRatio_first_hit.pdf

[zihlmann]

Do we understand what the origin of the little hump at negative 4ns is in MC, and why it is at -3ns for DATA in the plot of the TOF delta_t?

[sdobbs]

@zihlmann - there is some evidence in the MC that it is from points that have a single-ended hit in one plane, and no hits in another plane - see earlier post - https://github.com/JeffersonLab/halld_recon/issues/780#issuecomment-2010197401

[jrstevenjlab]

Following up with a couple more studies to wrap this up: I've repeated the comparison of the ratio of BRs for the eta and omega using this one run 51768 in the figures attached below. With the new MC there's reasonable agreement with the expectation from the PDG that is consistent for varied TOF DeltaT cuts.

etaRatio_both.pdf

omegaRatio_both.pdf

New MC is in progress for the rho and eta' channels, so @aaust and @imoewi01 can repeat their studies. Once those are complete I suggest we close the issue and release new software versions for others to produce new simulations.

[aaust]

Thank you @jrstevenjlab . With the new MC, I still see a small 2% discrepancy between the analysis with a 0.5ns cut on the TOF timing and 1.0ns, but it goes in the other direction. Widening the cut further does no longer change the outcome significantly: The yield for data increases more than for MC, so likely the resolution is not exactly matched.

[jrstevenjlab]

Right, I think you can see this in the plot from an earlier post in this issue of the DeltaT distribution after the hdgeant4 fix

https://github.com/JeffersonLab/halld_recon/files/14707439/DeltaT_TOF_first_hit_zoom.pdf

The data distribution is a bit wider than MC, so we could tune the paddle resolution parameter in mcsmear in CCDB. @zihlmann, do we have a measure of the TOF hit resolutions from data that we could use to fine tune this parameter?

https://halldweb.jlab.org/cgi-bin/ccdb/show_request?request=/TOF/paddle_resolutions:0:mc:2019-08-28_08-28-41

[imoewi01]

I have attached plots showing how the eta' cross sections change with the updated Monte Carlo.

The first result uses Monte Carlo that was produced just after the fix for the missing TOF hits. I find the cross section measured in the final state with four charged pions is roughly 25% larger than the final state with just two charged pions.

Repeating the measurement with Monte Carlo with the new TOF timing calculation (bottom plot), the discrepancy is less than 10%, but this time the two charged pion final state is larger.

I suspect the agreement between the final states will improve more if the timing resolution is tuned a bit, but this is clearly a big step in the right direction.

[sdobbs]

If we are doing some fine tuning of these delta T distributions, it would be good to look at the distributions in bins of track momentum, to see if there if are effects from tracking.

If I remember correctly, the measured paddle resolutions are more like 110 ps than the 130 ps used for mcsmear.

One other thing to consider is that the time resolution used for smearing hits is 1/sqrt(2) of the paddle resolution, which may not be a good assumption everywhere, like for the single ended paddles.

On Fri, Mar 22, 2024 at 9:31 PM William Imoehl @.***> wrote:

I have attached plots showing how the eta' cross sections change with the updated Monte Carlo.

The first result uses Monte Carlo that was produced just after the fix for the missing TOF hits. I find the cross section measured in the final state with four charged pions is roughly 25% larger than the final state with just two charged pions.

Repeating the measurement with Monte Carlo with the new TOF timing calculation (bottom plot), the discrepancy is less than 10%, but this time the two charged pion final state is larger.

I suspect the agreement between the final states will improve more if the timing resolution is tuned a bit, but this is clearly a big step in the right direction.

oldEtapXS.png (view on web) https://github.com/JeffersonLab/halld_recon/assets/19432989/8805d525-3496-45d4-b1ee-a015a8cf484e newEtapXS.png (view on web) https://github.com/JeffersonLab/halld_recon/assets/19432989/757480b5-ab0f-4b27-a008-d1c157ef9126

— Reply to this email directly, view it on GitHub https://github.com/JeffersonLab/halld_recon/issues/780#issuecomment-2016281000, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJAS2SLVSTVXGEMTDPHLJ3YZTLPXAVCNFSM6AAAAABCKV6OTWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJWGI4DCMBQGA . You are receiving this because you were mentioned.Message ID: @.***>

[jrstevenjlab]

Right, @zihlmann is fitting the DeltaT distributions to give us an estimate of how to modify the paddle resolutions and suggested to try 150 ps. And checking the dependence on paddle type and momentum is on the to do list.

[jrstevenjlab]

Some followup here for our discussion this morning: I've generated omega -> pi+pi-pi0 with TOF paddle_resolutions of 130, 145 and 150 ps and made DeltaT plots for data and these MC samples in bins of momentum. For example, the plot below is for a TOF paddle resolution of 145 ps and the momentum range from 1-12 GeV

DeltaT_TOF_KinFit_resol145ps_p1.0_12.0.pdf

More plots of the other resolutions and momentum slices can be found at the link below

https://halldweb.jlab.org/work/halld2/data_monitoring/jrsteven/TOFresol/

I'm also trying to repeat these studies for the BCAL timing DeltaT using the default algorithm and the same "first hit" for the BCAL time in hdgeant4. We'll see the plots are ready this morning or not...

[jrstevenjlab]

Proposed study: @zihlmann suggested we compute in simulation the same thing that he computes when calibrating the TOF, namely the difference in the time measured in the horizontal and vertical planes. This is straightforward to histogram from the smeared simulations files with a halld_recon plugin, but the information is not available in the REST files. I'll work on this in the next iteration.

[markdalton]

I found this with the calorimeter energy resolutions. The value that is input as the resolution in mcsmear is not necessarily the value that is extracted using some technique which is also applied to data. It was necessary to fine tune the input to obtain the desired extracted result.

[jrstevenjlab]

Here is a similar plot comparing data and MC timing differences for the BCAL using the nominal hdgeant4

DeltaT_BCAL_KinFit_default.pdf

and below using the "first hit" time in hdgeant4 using this flag USE_ENERGY_WEIGHTED_TIMES set to false

DeltaT_BCAL_KinFit_first_hit_bcal.pdf

[sdobbs]

Summary of plans from the analysis meeting today (feel free to correct if there is anything wrong):

• TOF resolutions need at least one more iteration
• Justin will look at the same paddle resolutions as in data (described in https://github.com/JeffersonLab/halld_recon/issues/780#issuecomment-2020367586) - but we agreed to focus on tuning the actual delta T distributions that we cut on
• Compare TOF delta T resolutions for tracks matched a point made from a double ended hit and a hit from a single ended paddle (cut on status flag and x,y position of the point)

Compare BCAL delta T resolutions to see if we need to loosen cuts for these types of tracks:

• recoil protons (any reaction)
• slow pions from Delta++ -> p pi+ (Farah)
• słów kaons from Lambda(1520) -> K+ p (Peter)

[farah88]

I have looked at slow pi+ from the Delta++ decay, which have momenta below 1 GeV. Within the uncertainties, the BCAL delta T resolutions are consistent between data and MC. There is a shift visible for the mean value which was also seen for the high momenta pions.

bcal_slowpionsfromDelta.pdf