2015 March 14

Notes from PMI meeting. 4/14/15

Attendees: Charles, Ben, Ilan, SJ, Dina, Peter, Seth, Barak, Riccardo, Daniel

What is PMI?

Protocols for representation / sampling; building scoring function. PMI also has output and input classes.

Our goals for PMI development.

• Publication of PMI.
• Clean, tested code.
• Webserver interface

Needs:

• Reduce dependence between classes. Limit interdependence of PMI objects. Be able to intersperse IMP code as needed (e.g., set up a special restraint with IMP, use PMI for sampling / analysis).

• Currently, PMI has classes and macros. The macros generate these classes. Should there be a completely script-free language? Need to formalize IMP classes first (Representation, Sampling, DoF). Then develop higher level “macro” interfaces.

• Expand plotting capabilities: Interface with chimera (whoever works on this should talk with chimera people). We have good analysis scripts already.

• Clustering is a memory hog. Also, symmetry is not taken into account.

• Symmetry in general as a restraint for sampling, restraint ambiguity.

• Topology file needs to be standardized. Simplify the goal of this file.

• DoF module. How to cleanly define movers...rigid bodies, super-rigid bodies.

• GPU must be implemented to be able to utilize MD.

• Set up benchmarks to profile IMP

Current state of PMI2

PMI2 was designed as a self-contained representation class. "System" class generates, decorates and returns an IMP hierarchy. Then, (the currently undeveloped) DOF class takes an IMP hierarcy, some other input and creates movers.

Create system; state (decorator); molecules; Representation (decorator).

Thoughts on Resolution

We currently specify resolution by integral residue units. What about volume representations..."fuzzy" residues...how do we define this in our representation nomenclature? What about abstract/crazy resolutions: e.g. proteasome as a cylinder? We need to define our base unit and then have a transformation to this by another. However, lets make sure that the most used, simple tasks are still easy to implement.

Andrej doesn’t like dynamic resolution…may be too expensive. Non-uniform bead resolution. Fix optimal resolution based on data. Do this as a preliminary step.

We can't predict the future, so trying to make a perfect generalization; may take forever and in the end, not be useful. Meanwhile, once people start using our tools, it will be very difficult to change formats, and break everyone's previously written scripts projects. Let's think about a creative way to keep this flexible.

Future goals: Web interface

Riccardo is trying to get someone involved to set up a webserver for PMI/IMP. Interactive manipulation of representation with the webserver (javascript). People are beginning to do integrative modelling and no slick way to accomplish this. People will just search for a webserver and try it, so ours should be fun!

A shorter-term goal is to get the webserver to create an input script that the user can run locally or on a publicly available cloud computational source. Standardized inputs (sequences, PDB, experimental data) with maximum size. Even include Modeller/ModWeb in the pipeline. Datamine from facebook...we know what you want to model.

Survey potential users. What do they want? EM + cryo + xtal structures is most used combination. Webserver for that?

Output: rmf files, plots, [clusters]

Moving forward

• Meet every month - Daniel to set up meetings.
• Meet in two weeks to chat about representation / resolution.
• SJ: formulate modeller script for pipeline.