Remove utility functions from representation.py?

[cgreenberg]

There are a number of functions that probably don't need to be member functions. Perhaps only functions that add member variables (like add_component_pdb) or restructure them (like creating rigid bodies) should actually be in representation.py. Then we could move things elsewhere and make it easier to read. Some things that could potentially be moved elsewhere:

autobuild_model() -- seems like this code should be part of a macro (instead of the macro simply calling this function) get_hierarchies_at_given_resolution() -- shouldn't that be a Selection task? shuffle_configuration() -- could be a macro? get_all_rmsds() setup_component_sequence_connectivity() -- shouldn't this be a macro or restraints function? optimize_floppy_bodies() -- could be a macro along with shuffle_configuration get_particles_from_selection_tuples() - should be a part of Selection draw_hierarchy_composition(), draw_component_composition(), draw_coordinates_projection() -- these seem like they could be part of a drawing utilities file get_random_residue_pairs()

[benmwebb]

I'm a bit puzzled by this talk of macros, since Python doesn't have macros. Do you mean functions?

[cgreenberg]

Actually they are classes that Riccardo built to automate model creation, sampling and analysis. I believe they are meant to (eventually) be the default way of using PMI (right?).

[benmwebb]

OK, so call them 'classes' then ;) Macros are something else entirely!

[cgreenberg]

Welllllllllll they act as a layer on top of core classes....macros is the closest english word I can think of.

[Pellarin]

I like the word macro, for computer modeling:

macro: Computing a single instruction that expands automatically into a set of instructions to perform a particular task.

PMI is a software for molecular modeling, and a macro is an automatized procedure in PMI. as simple as that. the name "classes" does not mean anything. As a user, I don't want a software that call automatized procedures "classes". Maybe "protocols" or something like that is better.

[Pellarin]

Actually they are classes that Riccardo built to automate model creation, sampling and analysis. I believe they are meant to (eventually) be the default way of using PMI (right?).

Yes I think they defines standard procedures that people can use and develop (very similar to what Rosetta does)

[Pellarin]

There are a number of functions that probably don't need to be member functions. Perhaps only functions that add member variables (like add_component_pdb) or restructure them (like creating rigid bodies) should actually be in representation.py. Then we could move things elsewhere and make it easier to read. Some things that could potentially be moved elsewhere:

autobuild_model() -- seems like this code should be part of a macro (instead of the macro simply calling this function) get_hierarchies_at_given_resolution() -- shouldn't that be a Selection task?

I need to cache some data in the Representation class to speed-up the selection. It will disappear when we'll be using IMP.atom.Selection(), that has internal caching.

shuffle_configuration() -- could be a macro?

No I prefer to have a new coordinate manipulation module instead

get_all_rmsds() setup_component_sequence_connectivity() -- shouldn't this be a macro or restraints function?

Yes, a restraint function. IMP.pmi.restraints.stereochemistry.SequenceConnectivity()

optimize_floppy_bodies() -- could be a macro along with shuffle_configuration

should be in IMP.pmi.samplers

get_particles_from_selection_tuples() - should be a part of Selection

Yes, but it will disappear.

draw_hierarchy_composition(), draw_component_composition(), draw_coordinates_projection() -- these seem like they could be part of a drawing utilities file

Yes

get_random_residue_pairs()

Should be in IMP.pmi.tools