yes - I was not part of this mailing list. please see below answers to the rest of the questions. On Jul 19, 2010, at 8:04 AM, Daniel Russel wrote:
>> 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 ? Resolution is no stored in the density files. >> What is the incidence/relevance of "arbitrarily" setting this >> parameter such as it is apparently done in this example ? >> Setting a wrong resolution will lead to wrong fitting results. In the next steps of the procedure we simulate the template protein to the resolution of the map and apply a cross-correlation measure to compare between the two. If the smoothed template significantly differs from the density map we will not be able to get correct solutions. >> >> 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). > >