RMSD, RMSF Refactor/Test Coverage

[jdetle]

Expected behaviour

RMSD and RMSF are highly used analysis modules. Both should follow the Bauhaus API and both should have full coverage.

Actual behaviour

MDAnalysis.analysis.rms.RMSD has no current test coverage, (which didn't expose the bug fixed by #889). (EDIT: fixed with PR #889) Both MDAnalysis.analysis.rms.RMSD and MDAnalysis.analysis.rms.RMSF are great candidates for a refactor to the Bauhaus API as well.

Proposal

Refactor MDAnalysis.analysis.rms.RMSD and MDAnalysis.analysis.rms.RMSF to conform to the Bauhaus API. As a part of this refactor we would add test coverage for RMSD. Additional work that could be done, but should probably be its own issue is creating the option for linear programming rmsd similar to that of MDTraj.

[orbeckst]

I generally agree to the refactor, Bauhaus-style. (And many thanks for PR #889 which added tests for RMSD).

For enhancements I would open new issues/PRs. I would also like to automate RMSD-calculation between two non-identical structures. PyMOL (and LSQMAN) have algorithms that do RMSD iteratively and throw out atoms that have high RMSD. The analysis.align module already has some code to create a sequence alignment (align.sequence_alignment() using biopython Bio.pairwise2) and use that one. Doing all of these things automatically would be useful – but all of this is better broken into smaller issues.

[sseyler]

Some time ago when the MDAnalysis.analysis.rms.RMSF class was added, @dotsdl mentioned in Issue #305 (referring also to #288) that certain useful features could be added in the future (e.g., on-the-fly fitting, saving data).

It might make more sense to open another issue for an RMSF (possibly also RMSD) functionality upgrade, but I wanted to note here that enabling on-the-fly fitting (in particular) would:

1. Be relatively straightforward.
2. Avoid the need to generate a new fitted trajectory for each unique atom selection prior to running RMSF.run(); I think this is particularly important as it saves (possibly major) headaches, especially when filesystem space is limited and one wants to avoid littering directories with otherwise identical trajectories differing only by fitting/orientation.
3. Also give (greater) commonality in features between RMSD and RMSF.

Note: much of the code in MDAnalysis.analysis.rms.RMSD.run() could then be pulled out as a separate function in the module or possibly implemented as a method in a base class for (any) rmsd-type analysis classes.

I would be happy to work on this as a separate issue and leave the Bauhaus-style refactoring here.

[jbarnoud]

For the record, the proposal about on-the-fly coordinate transformation is #786. I've been lacking time lately to work on it, but I can arrange some time if there is interest for the feature.

[sseyler]

@jbarnoud Ah, excellent! Not sure why I missed that.

[jdetle]

@sseyler @jbarnoud is there anything stopping me from working on the refactor?

[jbarnoud]

Please, go for the refactor. If anything, try to have as much of the logic as possible decoupled from the analyses class so it can be reused elsewhere.