SumEventsByLogValue does not do what I expect it to do (and hangs when I try to do what I expectedfrom it)

[Alex Buts]

from brief glance on the algorithm description and my understanding of the rocking curve technique (which may be well incomplete) I was thinking that SumEventsByLogValue is used to generate parametric plots (workspaces) E.g:

If I have a log value, which describes a scanning within some angle, the angle changed as sin(W*t) with time, and the source workspace, as usual, contains events against detectors, the algorithm would sort events according to time bins, for which each angle value was recorded. The result would be the function Events_of_(rotation angle) or (more physically meaningful after re-binning and coordinate transformation) Energy transfer_of_(rotation angle). This function may be non-unique if some particular energy transfers corresponds to different angles.

The re-binning option available in the algorithm works in similar way, but allows one to work with homogeneous functions only.

Following my expectations, I was trying to rebin LET event workspace LET00006278.nxs against log value total_counts which has 230 recoded integer values in the range from 0 to 10^6.

This operation hangs up Mantid.

Reading the algorithm description carefully I have found explicit warning against doing what I did, but attempt to do that should not hang Mantid and give better estimate of the time, left to complete the operation.

Needed: 1) Attempt to rebin data against integer logs with big number of measurements should give good estimate of the job ahead. Should be a possibility to cancel the wrong intended job

Desirable: 2) Rebinning against time intervals, associated with the log. (described above)

This is questionable ticket as I am not sure if many people think the similarly to myself as above.

[Russell Taylor]

Move the tickets I'm definitely not going to do this iteration so that I can better see the ones that I might.

[Nick Draper]

Moved to the Backlog after the code freeze for R2.6

[Russell Taylor]

Re #6494. Enable cancellation in case of erroneous input.

If the user inputs a log with a large range, print a warning and add progress reporting and a couple of bonus spots where the algorithm can be cancelled.

Changeset: 99c6830d05174a0eb94c0896802eb83a781b7b86

[Russell Taylor]

Re #6494. Handle variable deletion in a better way.

Changeset: b3b4e58e0c53e1853ed7ceaf90fd28295979c8f3

[Russell Taylor]

So I have dealt with Alex's "1)" above. "2)" will not be handled, though there is a possibility that an algorithm may come along later that will insert a scan_index log based on some input criteria such as this.

Tester: Try and run the algorithm with the inputs described above by Alex (the LET file is in the systemtests repository), i.e.:

ws = SumEventsByLogValue("LET00006278","total_counts")

The progress bar will move (extremely slowly) and the algorithm will be cancellable (it is possible that the cancellation may not be very responsive, but it's the best that can be achieved).

[Wenduo Zhou]

I ran the same script before and after merging the commit in this ticket. Both improvements were observed. So ticket is closed.

[Russell Taylor]

Re #6494. Enable cancellation in case of erroneous input.

If the user inputs a log with a large range, print a warning and add progress reporting and a couple of bonus spots where the algorithm can be cancelled.

Changeset: f956f09b2a65f38e44d86fb472808efa7aeadcf6

[Russell Taylor]

Re #6494. Handle variable deletion in a better way.

Changeset: 1ef43e31dd48eb5a12dd5b6a92b4943c7fc4a9be

[Stuart Campbell]

This ticket has been transferred to github issue ​7340