reintroduce 200ns delay for CRV event window start

[ehrlich-uva]

• old digis were produced relative to -protonBunchTime
• new digis are produced relative to -protonBunchTime-eventTiming.timeFromProtonsToDRMarker

The fcl setting physics.producers.CrvRecoPulses.oldDigis : true allows us to read old digis with the new code.

[FNALbuild]

Hi @ehrlich-uva,
You have proposed changes to files in these packages:

• CRVReco

which require these tests: build.

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

⌛ The following tests have been triggered for 99ba8c2: build (Build queue is empty)

About FNALbuild. Code review on Mu2e/Offline.

[FNALbuild]

☀️ The build tests passed at 99ba8c2.

Test	Result	Details
test with	✅	Command did not list any other PRs to include
merge	✅	Merged 99ba8c2 at 57339a5
build (prof)	✅	Log file. Build time: 04 min 14 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 1 files
clang-tidy	🔶	0 errors 62 warnings
whitespace check	✅	no whitespace errors found

N.B. These results were obtained from a build of this Pull Request at 99ba8c2 after being merged into the base branch at 57339a5.

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.

[ehrlich-uva]

I'm going to reintroduce the 200ns delay (eventTiming.timeFromProtonsToDRMarker). So the option for old digis is not needed anymore. Switching this PR to Draft for now.

[brownd1978]

Thanks for reverting this, I think its a step in the right direction. I'd like Richie to have a look and confirm this will result in synchronized event boundaries for tracker and CRV.

[brownd1978]

OK I see.

…

On Thu, Oct 17, 2024 at 9:18 PM ehrlich-uva ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In CRVResponse/fcl/prolog_v11.fcl <#1363 (comment)>: > @@ -9,7 +9,9 @@ #include "Offline/CommonMC/fcl/prolog.fcl" BEGIN_PROLOG - DigitizationStart: 400.0 //ns after event window start (i.e. 400ns after first clock tick after POT) --> 400ns...425ns after POT + DigitizationStart : 200.0 //ns after event window start (400ns...425ns after POT) It's not set in stone yet, but we wanted to start somewhere around 400ns after POT. — Reply to this email directly, view it on GitHub <#1363 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABAH57224CWHGGDBX6OJIVTZ4CD2HAVCNFSM6AAAAABQCXUGP6VHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDGNZWHE2TAMJTG4> . You are receiving this because you are on a team that was mentioned.Message ID: ***@***.***>

-- David Brown ***@***.*** Office Phone (510) 486-7261 Lawrence Berkeley National Lab M/S 50R5008 (50-6026C) Berkeley, CA 94720

[ehrlich-uva]

With this change, the event window starts (i.e. when TDC=0) at -protonBunchTime->pbtime_, which is the same event window start time the tracker uses. Zero suppressed data will be recorded starting at 200ns (=digitizationStart) after the event start time. The non-zero suppressed data (not implemented, yet) will get recorded starting from the event start time.

[kutschke]

For this round I think that the goal is to make all of the Tracker, Calo and CRV be consistent. If Richie signs off then I will merge.

In the future we may need another iteration to match what the DAQ timing really relative to the DR RF0 Marker will really do. But I think that this is good enough to encapsulate the later changes in one routine per subsystem.

[ehrlich-uva]

@kutschke I would like to run a few tests tomorrow to make sure it does what I want it to do. I will let you know when it is ready to merge.

[kutschke]

@kutschke I would like to run a few tests tomorrow to make sure it does what I want it to do. I will let you know when it is ready to merge.

OK - I will wait for both you and Richie.

[bonventre]

In the tracker we define digitizationStart/end in fcl as the effective time you want referenced to nominal proton arrival time, and then subtract the timeFromProtonsToDRMarker to get the actual value used by the digi making / hardware. Might make it easier to keep in sync if timeFromProtonsToDRMarker changes

[brownd1978]

It looks like this development has converged, is there anything holding up merging?

[ehrlich-uva]

@brownd1978 I sent an email around last week discussion the issue. The problem is that the CRV group is currently not planning to have this 200ns delay. So I'm not sure anymore, if I should have it in the simulation. Perhaps we could have a short Zoom meeting.