Context Navigation

Ticket #9079 (closed: fixed)

Opened 7 years ago

Last modified 5 years ago

PerformIndexOperations

Reported by:	Nick Draper	Owned by:	Harry Jeffery
Priority:	major	Milestone:	Release 3.5
Component:	Framework	Keywords:
Cc:		Blocked By:	#9072
Blocking:		Tester:	Roman Tolchenov

Description

Split from ticket #9072

A couple of other comments on the algorithm:

I found the name gave me no sense of what the algorithm does. Is there a better name? Or is it too late anyway? It's not obvious to me what this algorithm does that GroupDetectors doesn't.

Change History

comment:1 Changed 7 years ago by Russell Taylor

Comments from Owen:

The name could be changed. Better name suggestions welcome as I don't think it's being used in it's own right, but It is part of release 3.1. The algorithm does not require a mapping file and has a syntax that is compatible with MultiFile loading. Allows both cropping and summing. More information on allowed operations see http://www.mantidproject.org/PerformIndexOperations. Algorithm is used by CreateTransmissionWorkspace and ReflectometryReductionOne.

comment:2 Changed 7 years ago by Russell Taylor

GroupDetectors can be given lists of spectra instead of a mapping file, and these could be changed to accept a broader syntax. The algorithm has the option to keep or discard the ungrouped spectra (equivalent to cropping). However, it is true that it cannot do multiple groupings in one shot at present without the use of a mapping file.

comment:3 Changed 7 years ago by Owen Arnold

I'm not that familiar with GroupDetectors, but I think that if we can modify that algorithm to allow the "ProcessingInstructions" from PerformIndexOperations or appropriately named equivalent property to be provided instead of the mapping file then that would work as a solution. We could then deprecate PerformIndexOperations and replace the existing usage in ReflectometryReductionOne and CreateTransmissionWorkspace. I would be keen that the existing syntax for PeformIndexOperations listed here http://www.mantidproject.org/PerformIndexOperations#Description is preserved, as that matches the Multifile loading syntax that users are used to. The reflectometry group at ISIS have a strong opinion about this. Any thoughts?

comment:4 Changed 7 years ago by Nick Draper

I'm all for improving GroupDetectors if we can do it in a backwardly compatible way.

I think we could just adjust the inputs of spectra, workspace index (and maybe even detector_ids) to accept this syntax.

The one drawback would be that they could no longer be lists of integers, but would have to be strings.

comment:5 Changed 7 years ago by Nick Draper

Status changed from new to assigned

comment:6 Changed 6 years ago by Owen Arnold

I'm trying to think of a good solution here and have come to the following conclusions.

We should initially use PerformIndexOperations as a child algorithm in GroupDetectors, as the refactoring steps will be significant.
PerformIndexOperations works on workspace indexes, but there is in principle no reason why I couldn't adapt PerformIndexOperations to take spectrum numbers and convert them into workspace indexes for processing. To that end, handling detector numbers could be achieved in a similar way.
There doesn't seem to be a good way to use the same input properties and detect whether the user wants to use the new MultiFile type syntax or the existing syntax. In places they outright clash. For example: entering a WorkspaceIndexList comma separated means group the indexes provided. In the new syntax, this separator is an instruction to keep those indexes unmodified. We could either (a) Have a property which could be used to specify the interpretation method, which would default to the current one, or (b) Have separate input properties for the IndexOperation inputs.