Typically, a sample or reference run would be recorded for some minutes.
For proton charge normalization (for dream powder diffraction for instance), we currently find the time period over which the run was recorded, go back to the proton charge NXlog and integrate the charge over that period.
However, because of frame wrapping, it could be that some neutrons at the detector came from a pulse previous to the event_time_zero coordinate they have been assigned.
In most cases, being off by one or two pulses, over a run of several minutes would not matter.
For cases where fast recording rates are in use (fast FPS on the Orca imaging camera), this would not be the case. We would need to trace back and find the corresponding pulse for a given event_time_zero at the detector.
A solution for this would be to use the wavelength LUTs we already have. For a given event_time_offset, we find the wavelength and hence speed of the neutron. Trace backwards to find out which time at the source this corresponds to. And then find the closest previous pulse time in the nxlog.
This works as long at the proton charge nxlog contains times at the target and not at the accelerator source.
If the latter, then we would have to add an additional correction to account for the time the protons travel from accelerator source to target.
In any case, the idea here is to add an additional provider that can compute time at source. This can then be used by downstream packages to find the correct sections in the proton charge log.
Typically, a sample or reference run would be recorded for some minutes.
For proton charge normalization (for dream powder diffraction for instance), we currently find the time period over which the run was recorded, go back to the proton charge NXlog and integrate the charge over that period.
However, because of frame wrapping, it could be that some neutrons at the detector came from a pulse previous to the event_time_zero coordinate they have been assigned.
In most cases, being off by one or two pulses, over a run of several minutes would not matter.
For cases where fast recording rates are in use (fast FPS on the Orca imaging camera), this would not be the case. We would need to trace back and find the corresponding pulse for a given event_time_zero at the detector.
A solution for this would be to use the wavelength LUTs we already have. For a given event_time_offset, we find the wavelength and hence speed of the neutron. Trace backwards to find out which time at the source this corresponds to. And then find the closest previous pulse time in the nxlog.
This works as long at the proton charge nxlog contains times at the target and not at the accelerator source.
If the latter, then we would have to add an additional correction to account for the time the protons travel from accelerator source to target.
In any case, the idea here is to add an additional provider that can compute time at source. This can then be used by downstream packages to find the correct sections in the proton charge log.