CRT Offline - Calib

[henrylay97]

Description

This is part of a set of PRs designed to integrate updates to the CRT reconstruction to run it on data. To split up the diffs into more easily reviewable chunks there are 5 PRs to a common base branch. Once these have all been merged I will make a single PR to develop containing the full set of updates. Note, only on the final PR should the CI be run!

This particular PR introduces a simple service module that reads two text files containing pedestals and timing delays for each of the CRT channels / modules. This is a temporary solution which allows us to run a sensible first round of reconstruction. This will be replaced by use of the calibration database in the autumn.

Checklist

• Added at least 1 label from available labels.
• Assigned at least 1 reviewer under Reviewers,
• Assigned all contributers including yourself under Assignees
• Linked any relevant issues under Developement
• Does this PR affect CAF data format? If so, please assign a CAF maintainer as additional reviewer.
• Does this affect the standard workflow?

Relevant PR links (optional)

The final PR will rely on one in sbncode and one in sbnobj

Link(s) to docdb describing changes (optional)

CRT Data Reconstruction is detailed here: https://sbn-docdb.fnal.gov/cgi-bin/sso/ShowDocument?docid=36812

[absolution1]

Looks good Henry.
I've added an optional comment about where to actually store the data. It shouldn't hold up the PR process though.

[absolution1]

Not a strong feeling, but these might be better placed in sbnd_data or stashcache? (we tend to store training weights in those places rather than github)

[henrylay97]

Yeah, I'm happy to do so if we feel that would be better.

At the moment this follows the approach of the channel map directory (for relatively small text files) and longer term we will deprecate this method to make use of the calibration database.

@bear-is-asleep what is your take on this? Would you prefer they be moved to sbnd_data?

[bear-is-asleep]

Hi @henrylay97 , I think in general something like pedestals and detector responses should be stored in a database and not sbnd_data. It would be worth running this up the flag poll to a general analysis infrastructure discussion, since I don't think we've arrived at a consensus for where channel mappings, calibrations, etc. should go.

For now though, I think it'd be fine storing it where it is now.

[henrylay97]

Okay, I think we agree then. We absolutely want to move to the database as soon as is feasibly possible.

[absolution1]

Hi @bear-is-asleep and @henrylay97
The suggestion for using sbnd_data or stashcache is purely as temporary storage, until there's database access readily available.
I don't think we generally store large static files in git or other version control software.

[absolution1]

same comment as above about location

[bear-is-asleep]

trigger build LArSoft/lar*@LARSOFT_SUITE_v09_91_02

[FNALbuild]

✔️ CI build for LArSoft Succeeded on slf7 for c14:prof -- details available through the CI dashboard

[FNALbuild]

✔️ CI build for LArSoft Succeeded on slf7 for e26:prof -- details available through the CI dashboard

[FNALbuild]

⚠️ CI build for SBND Warning at phase ci_tests SBND on slf7 for e26:prof - ignored warnings for build -- details available through the CI dashboard

🚨 For more details about the warning phase, check the ci_tests SBND phase logs

parent CI build details are available through the CI dashboard

[FNALbuild]

❌ CI build for SBND Failed at phase ci_tests SBND on slf7 for c14:prof - ignored failure for unit_test - ignored warnings for build -- details available through the CI dashboard

🚨 For more details about the failed phase, check the ci_tests SBND phase logs

parent CI build details are available through the CI dashboard