Powder ring detector mapping

[oerc0122]

Currently Horace expects each workspace in the nxspe file (i.e. signal as a function of energy transfer) to be described as a single effective or virtual detector. In the case of single crystal data, when the physical detector elements whose signal is accumulated into that workspace are adjacent to each other, this can make sense (see footnote). In the case of powder data, when all detector elements in a ring at a given scattering angle are summed it does not. Depending on the spectrum-to-workspace mapping file used by the data reduction script in Mantid, detectors of arbitrary physical locations can be added together, and there is no reasonable 'effective detector' representation. Even if the physical detectors form a full ring, the resolution function does not have circular symmetry (it is broken e.g. by the chopper rotation axis on MARI, MAPS and MERLIN).

The solution is to use the physical detector-to-workspace mapping now stored in the nxspe files (final implemented underway) to randomly sample from the constituent physical detectors of a workspace, rather than some notional 'effective detector'. This will solve the problem of dealing correctly with the resolution function in the case of powder map files.

An intermediate fix is to use just 1:1 map files even for powder data, when the 'effective detectors' are good approximations.

Footnote: For example on MAPS with single crystal data each workspace accumulates the signal of four adjacent detector elements along the length of a position sensitive detector 3He tube; the effective detector parameters correspond to a single detector with four times the length of