Harmonize semantics of `select` keyword in various places

[ollyfutur]

Is your feature request related to a problem?

In various classes or functions, a select keyword is provided to perform a selection on the provided AtomGroups. E.g. RMSD, alignto
The API is somewhat inconsistent:

• many analysis classes (RMSD, PCA…) use as default select='all', which performs internally a ag.select_atoms(select) that silently sorts the provided atomgroup, which is sometimes undesirable. They do not accept None to avoid the selection altogether.
• alignto defaults to None and has a special case when "all" is provided, avoiding reordering.

Describe the solution you'd like

I see two options:

• I personally think those functions/classes should not have the responsibility of selecting atomgroups, since this can be easily done upstream by the user. This also leads to a lot of code reduplication. I would consider in the long run to deprecate select in most places, and recommend to always explicitly provide an (ordered) AtomGroup.

Describe alternatives you've considered

• If the keyword is kept, I think its behavior should be harmonized and match the behavior of AtomGroup.select_atoms, which always sorts. None should be always accepted to avoid any selection.

Additional context

I have submitted a PR #5296 implementing the second solution for analysis.rms.RMSD, but I now realize the problem applies to many places.

[IAlibay]

I believe the aim is to move away from select and just use AtomGroups for 3.0. However, this is a large API breaking change, so we aren't planning to do it until we get closer to 3.0.

[ollyfutur]

I believe the aim is to move away from select and just use AtomGroups for 3.0. However, this is a large API breaking change, so we aren't planning to do it until we get closer to 3.0.

I see, so with respect to #5296 should we finalize? These are many other instances where a similar select=None could be implemented in the analysis module alone:

• analysis.align.AlignTraj
• analysis.align.AverageStructure
• analysis.pca.PCA
• analysis.diffusionmap.DistanceMatrix
• analysis.gnm.GNMAnalysis
• analysis.helix_analysis.HELANAL
  etc. etc.

Since I did the work and it should not break any existing code, I suppose we can proceed with my PR for RMSD for now. Otherwise I am also happy to abandon it and delay everything to 3.0.

Ultimately the use case is not that common. For the record, it happened to me when I had to compare a trajectory to a reference with a different ordering of atoms, so I reordered the atomgroups and expected RMSD to keep my ordering. There are many workarounds so it may not be a critical feature to add now.

[ollyfutur]

Somewhat related to #2369

[orbeckst]

Thank you for looking into our (uneven) API in analysis. I am looking forward to 3.0 for a cleaner API (but not looking forward to the user grief...).

In the meantime I am in favor of updating analysis classes on an as-needed basis as proposed to also accept None with semantic of "use atomgroups unchanged". alignto is the exception but I think we should just keep it that way and don't break code (until 3.0).

@MDAnalysis/coredevs any concerns/suggestions?