> I started my IMP apprenticeship by trying to run and understand the example script local_fitting.py script. I spent some time rewritting it and parsing the documentation, and I come to you now with remaining questions. I am pretty new to the CryoEM field, so I will probably ask naïve questions. If some of these questions can be answered by reading a manual, please tell me which manual and I will be glad to read it. I'm not very familiar with the rigid fitting and em code, so I will just answer the general IMP questions. I've cced Keren who wrote that code in case she is not on this list.
> 1.) As a first remark concerning this script, the module IMP.algebra is used throughout the script, though never imported. Funnily, it puzzles my PyDev plugin but does not appear to lead to execution problems. Now that you mention it, it is puzzling. Various other modules depend on IMP.algebra and the result is that it is imported when you import say, IMP.core. But why this is, I don't really understand.
> 2.) I have problems wit regard to the resolution parameter and its apparent absence in density maps : > at line 30 the header of a loaded density map is modified. > dmap.get_header_writable().set_resolution(resolution) > I though, the idea was to fix a possibly distinct resolution value for the resampled map; so I commented the line and replaced it by > sampled_input_density.get_header_writable().set_resolution(resolution) > at line 36… Which resulted in an error during the local fitting process. > I thus checked wether the map header contained a resolution or not : > >>> dmap.get_header().get_has_resolution() > False > >>> dmap.get_header().get_resolution() > nan > Does the resolution never appear it map files ? > What is the incidence/relevance of "arbitrarily" setting this parameter such as it is apparently done in this example ? > > > 3.) I don't fully understand the way objects share elements, and what happens when these elements are moved. > For instance, the three objects : > line 19 : mh=IMP.atom.read_pdb(IMP.em.get_example_path("input.pdb"),m,sel) > line 24 : ps= IMP.Particles(IMP.core.get_leaves(mh)) > line 58 : prot_rb = IMP.atom.setup_as_rigid_body(mh) > > seem to share atoms since when moving : > line 60 : IMP.core.transform(prot_rb,local_trans) > it looks like every atoms in mh and in ps have also been moved. > > I thus have the feeling that all three objects share references on the same atoms. Yes. Particles, Restraints and other things inheriting from IMP.Object are not copied (or copyable). So get_X methods return a shared object when it is an IMP.Object.
> If this is true, I don't understand what happens when iteratively applying transformations to prot_rb at the end of the script : > line 100 : prot_rb.set_transformation(fitting_sols.get_transformation(i)) > line 102 : rmsd=IMP.atom.get_rmsd(IMP.core.XYZs(ps),IMP.core.XYZs(IMP.core.get_leaves(mh_ref))) > line 103 : IMP.atom.write_pdb(mh,"temp_"+str(i)+".pdb") > Since the transformations are applied iteratively, I would expect them to be composed; hence, parsing from 1 to fitting_sols.get_number_of_solutions() > in this order or in reverse order would not lead to the same result. I checked this behavior, and the solutions are (happily) the same whatever the order in which they are parsed... and I can't guess why… See below.
> > 4.) Is there a difference between prot_rb.set_transformation and IMP.core.transform ? Yes, and this has been a constant source of confusion, so a way of simplifying it would be nice. The current orientation of a rigid body is defined by a transformation (equivalent to the x,y,z coordinates of a simple point). set_transformation() replaces this transformation with another one (equivalent to set_coordinates() on an IMP.core.XYZ). transform() transforms a rigid body, that is it composes the previous transformation with the supplied one and calls set_transformation() with that (equivalent to transforming the coordinates of an IMP.core.XYZ).