Closed jrstevenjlab closed 6 months ago
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.
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.
Yes, I 100% agree - we'll need to look more into this, but simulations with this bug should not be used.
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.
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.
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.
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: @.***>
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
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.
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?
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.
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:
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.
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: @.***>
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
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?
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.
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?
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.
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.
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?
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.
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:
Thanks @aaust - I wonder what happens if you just cut on the kin fit times, not the measured times.
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:
@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.
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
There are a couple interesting features in these plots:
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
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.
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.
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?
@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
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.
@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.
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.
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)
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.
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.
For completeness, I am also linking to the meeting page for Tuesday's analysis meeting, where additional slides are linked to.
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
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
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)
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
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?
@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
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.
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.
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.
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?
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.
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: @.***>
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.
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...
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.
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.
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
Summary of plans from the analysis meeting today (feel free to correct if there is anything wrong):
Compare BCAL delta T resolutions to see if we need to loosen cuts for these types of tracks:
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.
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