CropWorkspace not useful on ragged workspaces

Bugs
1

Suppose I have a workspace where the X values don’t quite match between spectra, and I want to crop based on Xmin, Xmax:

Expected behavior

CropWorkspace includes only those data points in the range, perhaps with padding if the spectra would be of different lengths. Bins where all X values are out of range will be removed. Preferably, the workspace should be no longer (in number of bins) than the longest good portion of any spectrum, with spectra being shifted with respect to each other (in terms of bin numbers) if necessary.
Padding bins should be set to E=Inf or masked or some similar value such that a weighted average, integral, etc of the spectrum ignores them.

Actual behaviour

The workspace is not cropped. The X values are copied across in their entirety including those below Xmin or above Xmax. The Y and E values outside the range are all set to zero.

Steps to reproduce the behavior

Try this (as shown it crops a Point workspace but is easily modified to generate a histogram workspace which shows the same behaviour):
ws=WorkspaceFactory.create("Workspace2D",NVectors=2,XLength=6,YLength=6)
ws.dataX(0)[:]=[1.0,2.0,3.0,4.0,5.0,6.0]
ws.dataX(1)[:]=[1.0,2.0,3.0,4.0,5.1,6.2]
ws.dataY(0)[:]=[3.0,6.0,9.0,12.0,8.0,4.0]
ws.dataY(1)[:]=[3.1,6.1,9.1,12.1,8.1,4.1]
AnalysisDataService.addOrReplace("Uncropped",ws)
CropWorkspace(InputWorkspace="Uncropped",XMin=1.5,XMax=3.5,OutputWorkspace="Cropped")

In this example the cropped workspace ought to include only the points at x=2 and x=3.

Platforms affected

Using the “Muon Nightly Build” from the Download page (3.11.20180103.1049) on Windows 7: may affect others

2

I’ve been caught out by this one again. The use case being using FFT with only real input data, then cropping to select only the real part and a subset of frequencies (where I might expect a peak). I still get a long workspace with a single spectrum and a lot of bins with y=0.

The work around is to do the crop in two stages, first the subset of spectra and then the X range, but this shouldn’t really be necessary.

(Recent nightly 4.2.20200229.709)

3

For ragged workspaces, setting bins outisde the range to 0 is the intended behaviour of CropWorkspace. Out of interest can I ask what you are then using the cropped workspace for that makes this behaviour undesirable?

4

The procedure is: load runs in turn, group and pre process data, do FFT on them, crop to a frequency range where I expected a signal, conjoin the spectra with a log value such as temperature as the Y axis, then do a 2D colour plot which should not have blank areas at the sides. There are work arounds such as the double crop, or conjoining the time spectra first and then using ExtractFFTSpectrum.