SofQW3 width calculation wrong in non PSD case

[Martyn Gigg]

In the case of a non-PSD detector the SofQW3 algorithms are calculating the width of a detector in too basic a way. They are simple finding the total angular width of the instrument and dividing it by the numbers of detectors.

For instruments with gaps this will give to be an width. The actual shape of the detector needs to be taken into account.

Test script:

test = Load(Filename="MARIReduction.nxs")

Rebin_params='.2,.02,5.5'
SofQW3(InputWorkspace='Test',OutputWorkspace='Test',QAxisBinning=Rebin_params,EMode='Direct')

[Martyn Gigg]

Avoid name clash with enumerations in geometry. Refs #7510

You couldn't include ReferenceFrame & PolygonEdge in the same file.

Changeset: 184b5110bf9a7c244c099db25381fcbfc70ca092

[Martyn Gigg]

Fix ITableWorkspace from python to allow all integer col types.

Not completely relevant here but it came up while I was trying to look at something and it's so small I thought it worth fixing. Refs #7510

Changeset: 77f90376a8d7a1955a4cd6b7c4db428ebf8f0d9e

[Martyn Gigg]

Use detector shapes for SofQ width calculations in NonPSD mode.

A DetectorGroup is assumed to contain detectors at the same r, theta & shape and the first is used.

Refs #7510

Changeset: 9280e4a49dd13cea0892f414b4bc8df2879de027

[Martyn Gigg]

Move messages to log at debug instead of information. Refs #7510

Changeset: a345b7a7a53d292ccb2dd9c272ca111172d50cdb

[Martyn Gigg]

Branch: bugfix/7510_sofqw_widths_nonpsd in both systemtests & main code repository

Tester: Use the script above and check that SofQW3 runs correctly and gives broadly the same shape before and after the changes. The underlying numbers will differ slightly, a CheckWorkspacesMatch before & after should reveal this.

[Samuel Jackson]

Merge remote-tracking branch 'origin/bugfix/7510_sofqw_widths_nonpsd'

[Stuart Campbell]

This ticket has been transferred to github issue ​8355