Repository navigation
random time offset shift #22
Description
Currently the ICP randomizes event time offsets, e.g. https://github.com/ISISNeutronMuon/ISISICP/blob/bf3fc2fb38d0de4a476a1f5f9371402e0120d384/newicp/isiscrpt.cpp#L1127 & https://github.com/ISISNeutronMuon/ISISICP/blob/bf3fc2fb38d0de4a476a1f5f9371402e0120d384/newicp/NeXusEventCallback.cpp#L269
This is reflected in a nexus file by setting event_time_offset_shift to "random".
My understanding (@FreddieAkeroyd may be able to correct) is that this was to avoid artifacts in downstream analysis software.
We should figure out whether or not we need to do this, and if so whether it should be done
- in hardware
- when converting UDP -> ev44
- in the nexus filewriter
- in downstream analysis software
Activity
FreddieAkeroyd commentedon Nov 26, 2025
Ideally we don't want to do random shifts, but it was done due to issues seen in display/analysis if you assume all events are at the centre of the time window. A "beating" effect was seen in monitors, probably get some effect on summing across banks too. If we can store at full clock resolution i hope this will not be needed. how does our TOF clock resolution compare to what SNS ORNL and ESS achieve?
FreddieAkeroyd commentedon Nov 26, 2025
if we have to randomise, we previously chose to do it early on so analysis software didn't potentially give a different (but not scientifically significant) answer each time a program was run
Tom-Willemsen commentedon Nov 28, 2025
I think from testing on EMMA the hardware binning was 20ns. Is that low enough that random shifts then won't be needed?
FreddieAkeroyd commentedon Dec 1, 2025
I feel it likely will be, we had issues with some instruments with 500ns bins but this is an order of magnitude higher resolution.
Tom-Willemsen commentedon Dec 1, 2025
I'll close this issue for now then - we can reopen if needed later.