Charged shower veto issue in danarest

[jonzarling]

By default a shower is checked for any nearby projected tracks. It's rejected as a "neutral" shower if it's too close to a track, see default cuts here: https://halldweb.jlab.org/work/halld2/data_monitoring/RunPeriod-2023-01/mon_ver04/Run121206/HistMacro_Matching_FCAL.png

These cuts are supposed to be modifiable on the command line, but it looks like they only take effect on hit-level / smeared MC. Using a danarest file it looks like either the cuts are already pre-applied or the default is somehow not being overridden. See a comparison in the picture below

Example MC files to reproduce can be found on the farm here: /w/halld-scshelf2101/home/jzarling/github_issues/NeutralHypo_ChargedReject_danarest. This contains danarest, and smeared sims, and a jana-config where the charged shower veto has been turned off in the FCAL.

[jrstevenjlab]

It looks like the issue is the NeutralShower factory checks if the shower matches the track using the DDetectorMatches class

https://github.com/JeffersonLab/halld_recon/blob/master/src/libraries/PID/DNeutralShower_factory.cc#L166C39-L166C39

That map of matches between tracks and showers is created when the REST file is produced with the cut on the FCAL DOCA parameter (FCAL:CUT_PAR1) used at the time of production. Since the DDetectorMatches object is retrieved directly from the REST file and not re-computed by default when you run something like the ReactionFilter over the REST file, the list of matches won't be modified by changing FCAL:CUT_PAR1.

So to see the entries below the default DOCA cut one would need to recreate the FCAL detector matches with the desired DOCA cut and use that instead of what's retrieved from the REST file by default. I'd have to think about the simplest way to implement that, but it could be done when this object is retrieved from the REST file in

https://github.com/JeffersonLab/halld_recon/blob/master/src/libraries/HDDM/DEventSourceREST.cc#L1565

We do something like this for the DIRC when we want to recompute the PID likelihood at analysis time from the data stored in the REST file, rather than using the likelihood values stored when the REST file was produced.