\(\renewcommand\AA{\unicode{x212B}}\)

RebinByTimeAtSample v1¶

../_images/ImageNotFound.png — Enable screenshots using DOCS_SCREENSHOTS in CMake¶

Summary ¶

Rebins with an x-axis of relative time at sample for comparing event arrival time at the sample environment.

Properties ¶

Name	Direction	Type	Default	Description
InputWorkspace	Input	IEventWorkspace	Mandatory	An input workspace containing TOF events.
Params	Input	dbl list	Mandatory	A comma separated list of first bin boundary, width, last bin boundary. Optionally this can be followed by a comma and more widths and last boundary pairs. Values are in seconds since run start.
OutputWorkspace	Output	MatrixWorkspace	Mandatory	An output workspace.

This algorithm is used to determine the relative time (since the start of the run) that events interacted with the sample. Histogramming via rebinning allows statistics to be increased and output data sizes to be made manageable. This is useful for overlaying fast log data and filtered events workspaces. The filtering calculations are the same as used in GenerateEventsFilter v1 for the elastic case. Note that the current implementation of this algorithm assumes elastic scattering only.

\[TofFactor = \frac{L1}{L1 + L2}\]

Where TOfFactor is used to account for flight paths.

This algorithm rebins an EventWorkspace according to both the pulse times of each event, the time of flight, and the L1 and L2 distances. This algorithm is an extension of Rebin v1 and RebinByPulseTimes v1, which rebin by TOF an PulseTime respectfully.

The Params inputs may be expressed in an identical manner to the Rebin v1 algorithm. Param arguments are in seconds since run start. Users may either provide a single value, which is interpreted as the step (in seconds), or three comma separated values start, step, end, where all units are in seconds, and start and end are relative to the start of the run.

The x-axis is expressed in relative time to the start of the run in seconds.

This algorithm may be used to diagnose problems with the electronics or data collection. Typically, detectors should see a uniform distribution of the events generated between the start and end of the run. This algorithm allows anomalies to be detected.