Skip to content

Updates for first reprocessing of PDS products in spring productions#876

Open
mvicenzi wants to merge 69 commits intorelease/SBN2025Afrom
feature/mvicenzi_repro_step1
Open

Updates for first reprocessing of PDS products in spring productions#876
mvicenzi wants to merge 69 commits intorelease/SBN2025Afrom
feature/mvicenzi_repro_step1

Conversation

@mvicenzi
Copy link
Member

@mvicenzi mvicenzi commented Dec 8, 2025

This PR contains the required updates and fhicls to enable the first reprocessing of light products for the SBN2025 spring productions (both MC and data). In particular, the following changes are implemented:

  • MC2 tune (SPR + sim gain tune)
  • MC3/4 tune (SPR + sim gain tune)
  • Simulation of timing delays from database in overlays
  • Noise in MC waveform turned off for overlays
  • Overlay waveform chopping
  • DetSim + Overlay stage reprocessing fhicl(s)
  • Reco gain tune for run2/3/4
  • SPEArea database for optical reconstruction in data/overlays
  • OpHit recalibrator module for data
  • formally same reconstruction algorithms for data and MC (including pedestal's)
  • “MCStage0” reprocessing fhicl(s)
  • Data “stage0” reprocessing fhicl(s)

This PR depends on:

mvicenzi and others added 30 commits May 23, 2025 00:17
…plate

It used to end when the template SPR goes under 1e-4 ADC#.
Now it needs to stay within +/- 1w-4 ADC# for 20 nanoseconds.
This should make it possible to include undershootings.
All these parameters are currently hard-coded.
Good catches on names and strings.

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Trigger simulation modules now support input tags with process name [private]
Michael Carrigan and others added 21 commits December 12, 2025 10:36
Also requires the replacement of obsolete CreateAssns().
* removed unused headers and dependencies, added missing ones
* updated exception error message
* using `make_unique()` instead of `new`
Algorithmic code is still there, probably unused.
Also fixed a preexisting issue with (obsolete) FHiCL job configurations.
@mvicenzi mvicenzi removed the request for review from gputnam January 19, 2026 23:05
@mvicenzi mvicenzi force-pushed the feature/mvicenzi_repro_step1 branch from fdd76d8 to 419088b Compare January 19, 2026 23:45
@mvicenzi mvicenzi force-pushed the feature/mvicenzi_repro_step1 branch from 419088b to c435bf2 Compare January 20, 2026 00:01
@mvicenzi mvicenzi marked this pull request as ready for review January 20, 2026 00:16
Copy link
Member

@PetrilloAtWork PetrilloAtWork left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I could not find anything positively wrong.
However, I feel this is set up to add the n+1 layer of nightmare to configuration maintainers: with the fact that we discussed the workflow patterns many times together, and having laid out in front of me all the changes, I still had very hard time understanding the meaning of many of the choices, and their reasons. This may be mitigated by generously adding inline explanations or, if available, references to external documentation (like clear DocDB presentations). Especially useful would be to add a general introduction to many of the job configurations, to help people do fewer mistakes when they copy those into new ones for different data periods or samples.
I leave this unapproved (not disapproved either) for the first round. We (you and the release managers, mostly) may decide on the priorities of the changes suggested in this review with the merge of as-is material.

(Oh, there is actually one explicit request of changing the name of speAreas.fcl)

Comment on lines +602 to +604
// FIXME FIXME: temporary override to chop off flat tails after data waveform ends
// timing shift between data/mc event should be tuned so that this never (?) happens!
//adcVec.push_back( overlayOpWave.baseline + (wvfm[idxWvfmEntry] - simBaseline) );
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since now this while is a pointless loop, I suggest to comment the whole loop out and replace it with idxWvfmEntry = wvfm.size(); (for good measure; currently idxWvfmEntry is not used any further).
In addition, to increase the visibility of the FIXME comment, I would add it in Doxygen format (a @todo block).

* fraction of each dimension the cathode is extended for the purpose of
* determining the crossing of the particle (see the documentation above).
* * `LogCategory` (string, default: `SelectCathodeCrossingGenParticles`):
* message facility stream name where to write console messages to.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* message facility stream name where to write console messages to.
* message facility stream name where to write console messages to.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, a most excellent module, if I may say so.

Comment on lines +213 to +218
double totalDelay = 0;
if(fParams.doTimingDelays) {
totalDelay -= fParams.timingDelays->getLaserCorrections(channel);
totalDelay -= fParams.timingDelays->getCosmicsCorrections(channel);
}
microsecond const timeDelay { totalDelay };
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest the delay to be represented immediately in microseconds, to explicitly and directly make a statement of each individual correction:

Suggested change
double totalDelay = 0;
if(fParams.doTimingDelays) {
totalDelay -= fParams.timingDelays->getLaserCorrections(channel);
totalDelay -= fParams.timingDelays->getCosmicsCorrections(channel);
}
microsecond const timeDelay { totalDelay };
microsecond totalDelay = 0_us;
if(fParams.doTimingDelays) {
totalDelay -= microseconds{ fParams.timingDelays->getLaserCorrections(channel) };
totalDelay -= microseconds{ fParams.timingDelays->getCosmicsCorrections(channel) };
}

However, note that the conversions of the delay components needs to be a time interval (util::quantities::intervals::microseconds) rather than a time point (as in microsecond); in the example it is assumed that it was somewhere stated that using microseconds = util::quantities::intervals::microseconds;.

std::uint64_t beamGateTimestamp,
detinfo::LArProperties const& larProp,
detinfo::DetectorClocksData const& detClocks,
icarusDB::PMTTimingCorrections const& timingDelays,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Having a reference here forces the service provider to exist.
I suggest replacing the interface to use a nullable pointer, so that when it is not needed the caller can opt not to load the service at all.
This should be paired to an assertion (along the line of assert(!doApplyTimingDelays || timingDelay);) in the algorithm to make sure that when needed the service provider is available.

It does break the symmetry with the other service providers in the interface, but that may be actually good as long as they are mandatory and this is not always so.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again some comment words about what this configuration does and what needs reprocessing would help.

IICARUSChannelMap: @local::icarus_channelmappinggservice
IPMTTimingCorrectionService: @local::icarus_pmttimingservice
@table::icarus_wirecalibration_minimum_services
IPhotonCalibratorService: @local::icarus_photon_calibration
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The @local is misaligned, and I think the idea was to have the single services included before the @table. All of this does not really matter, but if you get a chance fix it.

Comment on lines +41 to +42
ophituncorrected: @local::icarus_ophit_data
ophit: @local::icarus_ophit_MC
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This confuses me a lot.
Maybe specify which correction is left out?

Suggested change
ophituncorrected: @local::icarus_ophit_data
ophit: @local::icarus_ophit_MC
# ophit will produce recob::OpHit with all needed time corrections:
# - in pure MC, that is actually no correction at all (configuration below);
# - in data and overlay, time correction is needed so ophit must be
# overridden later to become the time correction module
# (run on top of uncorrected hits)
# ophituncorrected never includes time corrections
ophituncorrected: @local::icarus_ophit_data # from `icarus_ophitfinder.fcl`
ophit: @local::icarus_ophit_MC # from `icarus_ophitfinder.fcl`

crthit: @local::standard_crtsimhitproducer
crttrack: @local::standard_crttrackproducer
crtpmt: @local::standard_crtpmtmatchingproducer
crtpmt: @local::standard_crtpmtmatchingproducer
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I disapprove this change.

Suggested change
crtpmt: @local::standard_crtpmtmatchingproducer
crtpmt: @local::standard_crtpmtmatchingproducer

@table::icarus_pmtsimulationalg_standard_run2
}

icarus_simpmt_run4:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add a comment on the fact that icarus_simpmt_run4 holds for Run3 too.
Or else add its own configuration:

icarus_simpmt_run3: @local::icarus_simpmt_run4

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants