Modify Normalize by Monitor algorithm to work porperly.

[Alex Buts]

Recent changes to NormalizeByMonitor algorithm force algorithm to load monitors list from workspace, and use it if such list has been found.

There are substantial defects in the implementation:

1) It works correctly for MARI but not for MERLIN. The list of the monitors, displayed in the list box do not correspond to monitors spectra. (something to do with spectra-detectors map?)

2) The option to normalize by any detector's spectra has to be provided.

3) Unit tests to verify the code have to be expanded.

[Martyn Gigg]

Refs #4098. Remove code that looks like it was committed by accident.

Restores proper behaviour of NormaliseToMonitor

Changeset: e7a2af810582eb8379bf7e6776bc279f47308e9b

[Alex Buts]

Error with spectra-detector map has been fixed (Martin says so)

Enhancement described above remains

[Stuart Campbell]

Loading MER02257.raw with the monitors as a separate workspace.

When you try and use the monitor workspace you get the following error.

NormaliseToMonitor-[Error] Error in execution of algorithm NormaliseToMonitor:
NormaliseToMonitor-[Error] Only one of the MonitorSpectrum and MonitorWorkspace properties should be set

and as the spectrum list is a drop down box, you can't not select anything. It does grey out the spectrum list though when you select the monitor workspace.

[Alex Buts]

refs #4098 Hopefully this fixes the bug, identified during testing

Changeset: 3896495f778ab55892a51b40310b89e1fb28368d

[Alex Buts]

refs #4098 Hopefully this fixes the bug, identified during testing

Changeset: 3896495f778ab55892a51b40310b89e1fb28368d

[Ronald Fowler]

The algorithm does now report an error if trying to normalise using a separate workspace which contains more than one spectra. Normalisation using a detector rather than a monitor is possible and just generates a warning message that a detector is being used. The spectra used for normalisation may contain zeros which lead to Inf/Nan in the output, but this seems acceptable and plotting can deal with these points. The set of monitors available for normalisation is listed by the GUI for both Merlin and Mari.

No test scripts are provided to demostrate the use of NormaliseToMonitor, but results using the data set MER02257.raw look OK. Results using MAR11001.raw also appear OK. The algorithm warns but allows normalisation by a detector and by detector 4 which looks like a monitor but seems not to be marked as such. The algorithm reports an error if given an event workspace which it can't process.

A crash occurs if a certain (incorrect) sequence of commands is given: (1) load a data set such as MAR11001.raw into MantidPlot. (2) execute NormaliseToMonitor setting an output workspace and an (incorrect) MonitorWorkspace, e.g. MAR11001. This fails to run and reports correctly that the MonitorWorkSpace must contain only 1 spectra. (3) Run the algorithm a second time and reset the MonitorWorkspace to null. When this is run MantidPlot crashes with a segmentation fault on both RHEL5 and Windows32. This seems to be a problem with the treatment of parameters in the GUI. This bug also exists in the previous release version of Mantid, so it is not related to the changes made by this ticket.

[Stuart Campbell]

This ticket has been transferred to github issue ​4945