New atom selection mechanism

[MBartkowiakSTFC]

Description of work
The intention behind this PR is to implement a mechanism of selecting atoms which is:

1. Not attached to a specific trajectory file,
2. Transferable,
3. Easy to extend.

We can still discuss if the implementation in this PR meets the requirements.

This screenshot shows the carbon dioxide trajectory in which two out of three atoms have been selected in the molecules from the first half of the index range. This is not scientifically meaningful, but illustrates how the selection operations can be combined.

Fixes

1. New selection functions have been implemented to replace the classes we have been using so far.
2. The output of each selection function is a set of indices.
3. Selections are applied sequentially, and can be combined using set operations (union, intersection, difference).
4. ReusableSelection class stores a sequence of selection functions and uses JSON for saving and loading a sequence.
5. ReusableSelection.select_in_trajectory method takes a Trajectory instance as input, applies the selection and returns the resulting set of atom indices.
6. Analysis jobs save the JSON selection sequence as one of the job inputs, and an array of 0/1 values to mark the indices which got selected.

The JSON representation is saved as str:

The indices are saved as a mask array:

To test
All tests must pass.

[ChiCheng45]

Looks good. Just one thing about the SMARTS pattern matching. In the RDKit molecule object we use the Chem.rdchem.BondType.UNSPECIFIED for all of the bondtypes. This means that most SMARTS patterns you'd think should work won't and that is why the SMARTS patterns we use are a bit unusual.

The correct thing would be to set all the correct bond types and atom properties but I think this might get difficult to get working for a general molecule e.g. setting single/double/aromatic bonds for a benzene or cyclooctatetraene or some big protein.

[oerc0122]

Consider making these an Enum

[oerc0122]

Can you not iterate over the children directly?

[oerc0122]

Could be:

Suggested change

	self.molecule_names = [str(x) for x in self.system._clusters.keys()]
	self.labels = [str(x) for x in self.system._labels.keys()]
	self.molecule_names = list(map(str, self.system._clusters))
	self.labels = list(map(str, self.system._labels))

[oerc0122]

I will note you keep externally accessing these variables which are marked _private, suggest making them public.

[oerc0122]

Might be better as an Enum

[MBartkowiakSTFC]

One complication here is that these values have to be JSON encoded and decoded (and remain human-readable when saved as a text string). I am sure that it can be done. Do you think it is worth the effort?

[oerc0122]

I was actually referring to the 1, 2...
If you had:

class Modes(Enum):
    DIFFERENCE = auto()
    INTERSECTION = auto()
    UNION = auto()
...

        if self.mode_box.currentIndex() == Modes.DIFFERENCE:
            return "difference"
        elif self.mode_box.currentIndex() == Modes.INTERSECTION:
            return "intersection"
        elif self.mode_box.currentIndex() == Modes.UNION:
            return "union"

It removes magic numbers and ensures internal consistency a bit better if we ever add other operations.

As an aside, Enums can act as strings

[oerc0122]

elif?

[oerc0122]

Also probably Enum