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 JeffersonLab/halld_sim#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 Missing simulated TOF hits in smeared files after adding random triggers halld_sim#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 <#780 (comment)>, 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

pippim__B4
pi0pippim__B4
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]

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 Unexpected Charged RF Bunch behavior with missing TOF hits in simulation #780 (comment)) - 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

[sdobbs]

Thanks Farah! Could you also make these plots with a logarithmic y-axis? The problem with TOF efficiencies showed up with a difference in the tails of the distributions.

[farah88]

Here are the same plots with a logarithmic y-axis.

bcal_slowpionsfromDelta_logy.pdf

[rjones30]

Farah and all, Has anyone looked at this delta t BCAL distribution in MC vs real data without a sharp cut at 1ns? In our studies, we have seen a slowly decaying tail out past 10ns that starts where your hard right-hand cutoff shows up and goes down much more slowly in MC than in real data. That can affect our MC efficiency even though it does not mean that the central gaussian width is incorrect in MC.

…

-Richard Jones

On Wed, Mar 27, 2024 at 10:10 AM farah88 ***@***.***> wrote: Here are the same plots with a logarithmic y-axis. bcal_slowpionsfromDelta_logy.pdf <https://github.com/JeffersonLab/halld_recon/files/14774507/bcal_slowpionsfromDelta_logy.pdf> — Reply to this email directly, view it on GitHub <#780 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB3YKWGY3S5LGMA6JIT757TY2LAOBAVCNFSM6AAAAABCKV6OTWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRSHA3TCMJQHE> . You are receiving this because you commented.Message ID: ***@***.***>

[jrstevenjlab]

@rjones30, we have analysis trees with a 3 ns wide BCAL cut for a subset of the Fall 2018 data here

https://halldweb.jlab.org/wiki-private/index.php/Fall_2018_Analysis_Launch#Version13

@farah88, could you use those for the Delta++ plots so we might start to see this tail?

[sdobbs]

@farah88 - there is also a jana config file at that link that you can use to make new MC trees from your existing REST files to compare with these analysis trees

[farah88]

Alright, I will redo the plots for the Delta pions and post them as soon as I am done.

[aaust]

I made some plots with my old 2017 sample, but neither pions nor protons show a long tail in MC for positive values of deltaT:

pSlice0.00-11.00_Hist_ParticleID_Initial_Step0__Photon_Proton_->_Pi+_Pi-_Proton_Pi-_DeltaTVsP_BCAL.pdf
pSlice0.00-11.00_Hist_ParticleID_Initial_Step0__Photon_Proton_->_Pi+_Pi-_Proton_Proton_DeltaTVsP_BCAL.pdf

I will make new plots with the recently produced MC sample.

[rjones30]

Alex, you would need to extend these plots out to 20ns to see the full tail. It is not very high but it is very long, so that 10-15% of the charged hits fall somewhere in the tail. Maybe the easiest way to see it would be to look in the single particle gun sample that I posted to the wiki. <https://halldweb.jlab.org/wiki/index.php/Particle_Gun_Collection> -Richard Jones

…

On Wed, Mar 27, 2024 at 11:47 AM Alexander Austregesilo < ***@***.***> wrote: I made some plots with my old 2017 sample, but neither pions nor protons show a long tail in MC for positive values of deltaT: pSlice0.00-11.00_Hist_ParticleID_Initial_Step0__Photon_Proton_->_Pi+_Pi-_Proton_Pi-_DeltaTVsP_BCAL.pdf <https://github.com/JeffersonLab/halld_recon/files/14775765/pSlice0.00-11.00_Hist_ParticleID_Initial_Step0__Photon_Proton_-._Pi%2B_Pi-_Proton_Pi-_DeltaTVsP_BCAL.pdf> pSlice0.00-11.00_Hist_ParticleID_Initial_Step0__Photon_Proton_->_Pi+_Pi-_Proton_Proton_DeltaTVsP_BCAL.pdf <https://github.com/JeffersonLab/halld_recon/files/14775766/pSlice0.00-11.00_Hist_ParticleID_Initial_Step0__Photon_Proton_-._Pi%2B_Pi-_Proton_Proton_DeltaTVsP_BCAL.pdf> I will make new plots with the recently produced MC sample. — Reply to this email directly, view it on GitHub <#780 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB3YKWDEM2TPMAPM2RZK5L3Y2LS2TAVCNFSM6AAAAABCKV6OTWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRTGEYDQMBYHA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[s6pepaul]

I did a similar study for the Lambda(1520) analysis in pKK where I have a slow KMinus and a slow proton. I analysed 2018-08 ana launch ver13 which has the timing cuts opened to +/-3ns. For MC I produced a sample with the standard average time in the BCAL and the first hit time. The effect has some momentum dependence, so I show the plots once for 0-2GeV and then split in four bins (although one bin has almost no stats for the KMinus). The momentum range is quoted in the legends, so is the mean of the distribution. I did not fit for the mean, just used the histogram mean. Please note that all histograms are normalised to have an integral of 1 for better data/MC comparison.

There are definitely some tails in data that are not reproduced in MC. Also the means seem to match better with the first-hit MC. If useful I can fit the means and standard deviations of the distributions and provide some numerical values. But if we want to pursue this further, maybe it should get its own issue.

[jrstevenjlab]

For additional BCAL studies, please use the other issue thread #792

[aaust]

With the latest MC sample produced with 143ps resolution for the TOF, I still see about a 2% discrepancy between the default sample (0.5ns) and the widened selections:

The resolution made barely any difference, so I assume the discrepancy has another origin. It could be background, which is hard to estimate under the broad rho peak. However, I clearly see the acceptance increase more than the data when widening the cut.

[jrstevenjlab]

Thanks @aaust, the paddle_resolution currently in CCDB is 130 ps and I tried a few values before converging on 143 ps which provides a good agreement between the DeltaT width for charged pions in omega -> pi+pi-pi0 in data and MC, see attached figure with fit resolutions in the stats box

DeltaT_TOF_KinFit_resol143ps_p1.0_12.0.pdf

Based on this I'm ready to make 143 ps the default paddle resolution for Fall 2018 in CCDB, and I'm checking the other run periods now to see if this can apply to all periods.

Sean also suggested studying the timing resolutions for different paddle types, which requires going back to the REST files to access the DTOFPoint objects. I looked at run 51768, comparing the same omega -> pi+pi-pi0 events between data and MC and fit the DeltaT distributions for each paddle for comparison of their resolutions. Attached are plots of the DeltaT vs paddle number for data and MC for points with status==3, which means that plane had hits on both ends of the paddle

data_DeltaTVsBar_Status3.pdf
omegaMC_DeltaTVsBar_Status3.pdf

Fits to the resolutions for each paddle show that neither the data or MC have significant paddle dependence within the limited statistics of this one run

ResolutionByBar_Status3.pdf

For points that have status==2, meaning they have only have a PMT hit on one end of the paddle, those points primarily only occupy the inner two paddles which just have single-ended readout

data_DeltaTVsBar_Status2.pdf
omegaMC_DeltaTVsBar_Status2.pdf

The statistics are very limited here, but there doesn't seem to be a significant data/MC discrepancy within the errors here for these inner paddles either

ResolutionByBar_Status2.pdf

These results are all using the same DeltaT variable that we make a cut on in the ANALYSIS library and DSelector, where we agreed to do the tuning. Are we ready to declare this aspect of the issue closed?

I'll post shortly with a comparison of the mean time difference between planes that Beni requested.

[aaust]

Here is a summary of the timing distributions of the different MC samples with data:

The fix of the timing algorithm made a big change (red to green), but the expanding the timing resolution from 130ns to 143ns (green to blue) did not change much. The width of the central distribution is approximated well, but a fraction of the non-Gaussian wings are missing (log scale!).

[sdobbs]

It seems like we could declare the tuning done for now, and leave the tuning of the tails for a later project. Alex's results imply a per pion systematic of 1-2%, which is not too bad for now.

As a check, we could ask analyzers to compare the cross section results for the nominal TOF delta T cut and |Delta T| < 1 ns, until we have a few points to see how stable the results are.

[jrstevenjlab]

Right, @aaust's plots would indicate a 2% change for a 2 charged pion cross section or a 1% bias per track.

I made similar plot to Alex for the pions from the omega -> pi+pi-pi0 mass region and it looks like better data/MC agreement across the momentum bins than what is seen for the rho -> pi+pi-. These aren't perfect, but I'd be a little worried about further tuning the tails of the distribution unless we can identify the source.

DeltaT_TOF_resol143ps_p1.0_3.0.pdf
DeltaT_TOF_resol143ps_p1.0_12.0.pdf
DeltaT_TOF_resol143ps_p4.0_6.0.pdf
DeltaT_TOF_resol143ps_p7.0_9.0.pdf

with fits to Gaussian core
DeltaT_TOF_KinFit_resol143ps_p1.0_3.0.pdf
DeltaT_TOF_KinFit_resol143ps_p1.0_12.0.pdf
DeltaT_TOF_KinFit_resol143ps_p4.0_6.0.pdf
DeltaT_TOF_KinFit_resol143ps_p7.0_9.0.pdf

[zihlmann]

overall timing resolution of the tof represented as the time difference of the mean time from paddles in plane 1 minus the meantime of the paddles in plane 2 (this only has data from full length paddles with PMTs on both ends)

the fit range of the Gaussian is from -0.35 to +0.35 ns: 152ps / sqrt(2) is about 107ps for the paddle mean time resolution. Since the meant time MT is calculated as MT=0.5*(t1+t2) and assuming that the error of t1 is the same as t2 we find a timing resolution for t1 to be 107ps*sqrt(2) and we are back to a bout 152ps timing resolution for a single PMT.

Note: the above plot is from single track reconstruction there is no final state reaction defined.

[zihlmann]

Using a single effective light/signal velocity in the TOF paddles leads to a noticeable improvement in the proton pion separation at high momenta as shown in the four plots below where on the left the results from the past is used for run 51768 ver02 reconstruction (root file) and on the right a new reconstruction of tracks with a single velocity for all paddles. Most notably, the width of the pion peak is narrower.:

[jrstevenjlab]

Thanks, @zihlmann. This seems consistent with the conclusion we discussed at the Open Analysis meeting yesterday, slides here https://halldweb.jlab.org/DocDB/0064/006422/001/ChargedRF_4.2.24.pdf.

Short summary:

• The previous TOF calibration was done without the paddle-dependent propagation speed, so the time resolution we observe in the DTOFPoints stored in the REST file is worse (184 ps) than what could be achieved if a constant propagation speed was used (152 ps), as shown in the figures in your previous messages. Thus when tuning the smearing parameters for the hit resolution in MC we should expect to match this larger resolution for the existing REST files.
• In MC we don't calibrate out the time difference between the planes, so repeating the same procedure of computing the Mean Time Difference (MTdiff) between planes results in a worse resolution (220 ps) than what is really set in the CCDB for the MC (202 ps hit resolution)
• In the end, tuning the paddle_resolutions parameter in CCDB to match the PID DeltaT distributions between samples of pions from omega -> 3pi samples in data and MC appears to be consistent with the TOF-only resolutions determined from the MTdiff procedure.

So for generating new samples of MC to match the REST files from existing 2017-2020 data we will tune the paddle_resolutions parameter in CCDB based on the PID DeltaT for each period, and continue studying any sub-leading effects with the new simulations.

[jrstevenjlab]

Here are the DeltaT distributions for pions from omega -> 3pi for the 3 GlueX-I periods, each with the same paddle_resolutions parameter of 143 ps:

Fall 2018
DeltaT_TOF_KinFit_resol143ps_p1.0_12.0_2018_08.pdf
DeltaT_TOF_resol143ps_p1.0_12.0_2018_08.pdf

Spring 2018
DeltaT_TOF_KinFit_resol143ps_p1.0_12.0_2018_01.pdf
DeltaT_TOF_resol143ps_p1.0_12.0_2018_01.pdf

Spring 2017
DeltaT_TOF_KinFit_resol143ps_p1.0_12.0_2017_01.pdf
DeltaT_TOF_resol143ps_p1.0_12.0_2017_01.pdf

The Fall 2018 and Spring 2017 seem to agree reasonably well in the width of the DeltaT distribution with this resolution parameter, so I suggest we use the same parameter of 143 ps for these datasets.

The data seems to be significantly wider for the Spring 2018 data, so I would suggest that we increase the smearing parameter to match the resolution of this DeltaT distribution that we cut on in the analysis. I'll find a new value (around 155 ps) that should match what we observe in DeltaT, and post the plots before uploading these to the CCDB. Sound reasonable?

[sdobbs]

That sounds reasonable for now, though the fact that there's a difference for Spring 2018 suggests that it might be due to tracking, then.
But again, looking into that sounds like a longer-term project.

[jrstevenjlab]

Good point, for Spring 2018 we do have two batches of analysis launch with the wider timing cuts. For the plots above I've only looked at the last batch (42274-42559), but I can repeat it quickly for the first batch (40856-41102) to see if this is correlated with the known CDC degradation over the course of that run...

[jrstevenjlab]

I went ahead and put 143 ps for the paddle_resolutions into the main CCDB this morning for the 2017 and Fall 2018 periods.

For the Spring 2018 period, attached are plots with the same MC sample with 143 ps, but 7 different run numbers (see filenames) for each of the "batches" of that periods production. Note: these DeltaT distributions will be cutoff at 0.5 ns since most were produced with the nominal cuts, so we can only fit the gaussian core.

The first 2 runs from the first batches have better resolution, which matches the 2017 and Fall 2018 periods. However, the resolution steadily degrades over time as the run numbers increase. This matches the same timeline as the CDC degradation during the Spring 2018 period, so a degraded tracking resolution could be the cause of the degraded resolution in PID DeltaT variable for the TOF shown here. Note: the scale of this change resolution is at most a ~10% effect, with 128 - 143 ps covering the full range of observed sigmas.

One possibility is to degrade the TOF paddle_resolution to match this PID DeltaT variable in a batch- or run-dependent way, which would give us agreement in the efficiency of this cut in the analysis library. However, since there may be an underlying cause for the degraded resolution, this isn't really addressing the source of the issue which could have other implications.

DeltaT_TOF_KinFit_resol143ps_p1.0_12.0_2018_01_41102.pdf
DeltaT_TOF_KinFit_resol143ps_p1.0_12.0_2018_01_41257.pdf
DeltaT_TOF_KinFit_resol143ps_p1.0_12.0_2018_01_41482.pdf
DeltaT_TOF_KinFit_resol143ps_p1.0_12.0_2018_01_41632.pdf
DeltaT_TOF_KinFit_resol143ps_p1.0_12.0_2018_01_42059.pdf
DeltaT_TOF_KinFit_resol143ps_p1.0_12.0_2018_01_42273.pdf
DeltaT_TOF_KinFit_resol143ps_p1.0_12.0_2018_01_42559.pdf

[sdobbs]

Thanks, I would lean towards just putting in an average value for the Spring 2018 data, and live with some larger systematic uncertainty, until we understand what is happening in some more detail. Presumably the 10% variation in resolution leads to smaller variation on the overall efficiency.

[jrstevenjlab]

Ok, I'll loop over all the Spring 2018 runs to get an average value and put it in the CCDB

[jrstevenjlab]

Below is the TOF PID DeltaT distribution for 150 ps paddle_resolutions. Based on this I updated this table in CCDB with 150 ps for the full Spring 2018 period (runs 40000-49999), so we will use this average value until we better understand the batch/run dependence in the data.

DeltaT_TOF_KinFit_resol150ps_p1.0_12.0_2018_01.pdf

[jrstevenjlab]

Since this issue is now fixed in the latest release of hdgeant4 https://github.com/JeffersonLab/HDGeant4/releases/tag/2.39.0 and we now have the relevant resolution parameters updated in the CCDB, I'm closing this issue. We can re-open later (or start a new issue in halld_sim to fine-tune smearing parameters) if we have more studies on the impact with updated simulations, etc.