MSMBuilder 3

Abstract

This document is a collaborative wiki page for brainstorming the direction of new development efforts towards msmbuilder 3.

Enhanced usability
- Robust
- Informative error messages
- Sanity checking of inputs in library functions
Better error analysis
- Bayesian methods?
- Add script for Nina's method
New visualization tools
- Plot eigenvector components by state index?
- Plot eigenvector components by observables?
Clean up code
- Rewrite the Trajectory code.
  - "Smart" slicing and keeping track of the time index of every frame.
  - Use new PDB reader
- DRY the scripts. To the extent that they are "thin" wrappers for library functions, can they be auto-generated?
- Rewrite all of the non-RMSD C code (asa, rg, etc) in cython.
Improve documentation
- Bring the latex tutorial onto readthedocs.org
- Increase the amount of narrative content on readthedocs.org
New test systems and benchmarks
- Muller potential (?)
- BPTI (?)

Should all of the scripts be accessible under a single command?
- $ msmbuilder cluster
- $ msmbuilder setup
- $ msmbuilder assign
- RTM prefers yes.
Is it time to re-work our "best practices" to better include conformational change? TICA?
Should we reorganize the directory layout of the source code? Currently we have two main directories, src/python and src/ext. If you look at how a project like numpy or scipy is organized, the directory structure is by logical grouping instead. Like package/subpackage. It's not based on what language the code is in. This is, in RTM's opinion, related to the idea of bringing the current c code into cython and making it more "public" and robust.
How should we handle trajectory loading? Especially as we move towards a more "feature"ized representation, should we save those features to disk as opposed to reloading them every time? How can the metric object cooardinate trajectory loading so that we only load the atoms/regions that we care about and save memory?