Add example fcl to run reco and trigger in one job

[michaelmackenzie]

This reconstruction version will allow one to update the trigger reconstruction/results without the need for re-running the digitization stage (which can be very expensive in the case of producing mixed samples).

[FNALbuild]

Hi @michaelmackenzie,
You have proposed changes to files in these packages:

• JobConfig

which require these tests: build.

@Mu2e/write, @Mu2e/fnalbuild-users have access to CI actions on main.

⌛ The following tests have been triggered for d8d65f1: build (Build queue - API unavailable)

About FNALbuild. Code review on Mu2e/Offline.

[FNALbuild]

☀️ The build tests passed at d8d65f1.

Test	Result	Details
test with	✅	Command did not list any other PRs to include
merge	✅	Merged d8d65f1 at 408fdd7
build (prof)	✅	Log file. Build time: 09 min 38 sec
ceSimReco	✅	Log file.
g4test_03MT	✅	Log file.
transportOnly	✅	Log file.
POT	✅	Log file.
g4study	✅	Log file.
cosmicSimReco	✅	Log file.
cosmicOffSpill	✅	Log file.
ceSteps	✅	Log file.
ceDigi	✅	Log file.
muDauSteps	✅	Log file.
ceMix	✅	Log file.
rootOverlaps	✅	Log file.
g4surfaceCheck	✅	Log file.
FIXME, TODO	✅	TODO (0) FIXME (0) in 0 files
clang-tidy	✅	0 errors 0 warnings

N.B. These results were obtained from a build of this Pull Request at d8d65f1 after being merged into the base branch at 408fdd7.

For more information, please check the job page here.
Build artifacts are deleted after 5 days. If this is not desired, select Keep this build forever on the job page.

[FNALbuild]

📝 The HEAD of main has changed to 1b4b11f. Tests are now out of date.

[brownd1978]

Is the intent of this sequence to verify the trigger as it was run Online? If so, what is the point of running reco in this job?
It seems as if this config overrides the standard configuration Offline of configuration (ie makePH), so the reco results will be different from running Production/reco/Reco.fcl (ie what Pass1 runs). Is that the intent?

[brownd1978]

There doen't seem to be any action associated with this comment: is it planned to add this functionality or is the comment out-of-date?

[michaelmackenzie]

This comment was meant to give the intent of the fcl as a whole, rather than for a specific line.

[brownd1978]

I missed the #include of drop_trigger.
When re-processing early MDC2020 data dropping the trigger was required to avoid problems with evolved schema, but AFAIK that's not true today. Are there other technical reasons why the drop needs to be embedded in this script? If not, it could be mixed in at the final .fcl stage.

[michaelmackenzie]

I'm not positive if it's necessary, but the intent here was to produce a reco file with a single version of Online-configured reco instead of multiple versions.

[brownd1978]

Could this script be useful for comparing past/new triggers in a single job, event by event?

[michaelmackenzie]

It's possible, but I imagine you would need many input tag updates to not confuse the modules of which versions to select (e.g. TrigMakeSH --> TrigMakeSH:Reco).

[michaelmackenzie]

The goal here was to provide an example of how to re-run Offline and Online reco on an existing digi input, replacing the previous trigger results with updated ones. This is useful for trigger development, where you can produce a new reco dataset from an existing digi dataset after trigger updates, without the need for reproduction/mixing of the entire digi dataset. This is primarily useful for the "Triggerable" events in the digi dataset, which should be independent of the actual trigger decision.

[brownd1978]

I don't have a problem with the combining of re-running trigger with Offline reco, but I'm curious why just rerunning the trigger isn't itself a valid and complete test.
I'm also still concerned that the reco run by this script might produce different results from what's produced by Reco.fcl, due to different precursors. Have you verified that this output is identical?

[michaelmackenzie]

I think re-running the trigger and validating the results are identical is a useful test for Pass 1. The intent of this PR was to add an example fcl to produce a new reco dataset with updated trigger configurations, without the need for re-digitization or mixing. I wasn't intending this to be for this validation stage. Perhaps this is something that should be a separate Pass 1 fcl, without any Offline reco run?

I don't believe any of the prolog changes should affect Offline reco modules. I ran 100 CE+ events with OnSpill.fcl and OnSpillTrig.fcl and used the validation tools, where I only saw changes in the Online distributions (which was expected in this case).