Refactoring the EXPERIMENT_TYPE enumeration

[rhfogh]

The issue arises from Issue #1604, which proposes to the place the 'OSC' experiment type with a more relevant 'Rotation'. But teh experiment type enumeration (queue_model_enumerations.EXPERIMENT_TYPE_STR) seems a bit problematic in itself, as a basis for classifying experiments. Essentially it is a bit schizophrenic whether it classifies the purpose or the mechanics of the experiment, and some entries, like 'MAD - Inverse Beam', seem rather obsolescent. The current enumeration is:

EXPERIMENT_TYPE_STR = ExperimentType(
    "SAD",
    "SAD - Inverse Beam",
    "MAD",
    "MAD - Inverse Beam",
    "OSC",
    "Helical",
    "Characterization",
    "OSC",
    "Mesh",
    "Collect - Multiwedge",
    "Still",
    "Imaging",
)

If we look at the mechanics, a sensible set would be
'Rotation', 'Helical', 'Mesh', 'Still', 'Imaging', and possibly 'Line' (unless Line is the same as Helical).

If we look at the rest, ("SAD", "SAD - Inverse Beam", "MAD", "MAD - Inverse Beam", "OSC", "Characterization", "Collect - Multiwedge") they are all 'Rotation', or sets of 'Rotation'. Certainly the GPhL workflow enqueues them all as Rotation,in some cases with multi-trigger and offset (overlap) specification. Does it make sense to keep all these separate keywords, and to expect viewers to know how to treat them individually? What do they correspond to in terms of actual motor movements when specified on a single DataCollectionQueueEntry?

If this enumeration was more clearly defined and described it would be easier to use for e.g. display. Does anyone have some use cases for this?

[marcus-oscarsson]

Hm, I think we need to be more fine grained and at-least add Line, Characterisation, XRF and EnergyScan. If we are too general everything would be Rotational simply with or without displacement and with or without rotation :). Or at least that we could have a tagging mechanism where we could tag the intended use of the data collection.

I could actually imagine to both have the data collection types outlined above and a tagging mechanism for intended use ?

[rhfogh]

@marcus-oscarsson Line, Characterisation, XRF and EnergyScan make perfect sense, yes. And a tagging mechanism would also be a good idea. The hardest bit I guess would be to come up with a good set of tags that cover what people need but does not have tags that on one uses.

[marcus-oscarsson]

@rhfogh, Did you have a PR prepared for this ?

[rhfogh]

It was not quite this detailed, but I shall come up with something (as soon as I get another couple of things out of the way).

[rhfogh]

I have had another look at what it would take to clean this up. The first thing would be to merge EXPERIMENT_TYPE and EXPERIMENT_TYPE_STR into a single string enum, and change the names and values to a better set. One problem is that the values of EXPERIMENT_TYPE_STR (converted in the to_collect_dict function) are used in many places in the code - and the comparisons are all against explicit strings. That could be cleaned up as well. But there is the further problem that those strings are passed into LIMS systems, and here my refactoring could nto really go.

So, how much freedom do we have to change the values of EXPERIMENT_TYPE_STR? Do we have to keep them unchanged?