I agree set_is_optimized() is a very intuitive user interface but I appreciate it was hard to maintain for each attribute. Do we really need a different optimization for each attribute? I think it is enough to work at the particle level.
How about we deprecate XYZ::set_coordinates_are_optimized(), and add particle::set_is_optimzed() instead? It seems much easier to implement. I didn't think the coding / computational side through yet, but it might be simpler since it can be applied as a filter on containers. Daniel, I bet for you it might be easier to think how complicated this would be.
On Wed, Sep 25, 2013 at 11:48 AM, Daniel Russel drussel@gmail.com wrote:
> The cheaper way to keep them from moving is just to not add them to the > movers. The set_coordinates_are_optimized(false) approach was expensive > both computational (since the movers had to check each time they were > requested to move the particle whether it could actually be moved) and in > terms of code since the checks had to be consistently done in many places > (and weren't). > > > On Wed, Sep 25, 2013 at 1:44 AM, Davide Baù davide.bau@gmail.com wrote: > >> I still think that was a convenient way of keeping particles "untouched". >> It can be done in other ways, but I guess it will be computationally more >> expensive. >> >> Davide >> >> >> >> On Sep 24, 2013, at 9:06 PM, Yannick Spill wrote: >> >> I agree that this is the right way to go. Only MD needs to be changed in >> that respect i believe. >> >> On 24 sept. 2013, at 20:57, Daniel Russel drussel@gmail.com wrote: >> >> There hasn't been any systematic pass through things to make them >> consistent. That said, I think at this point most (all?) movers move the >> particles they are told to move. >> >> *Marking an attribute as not optimized has never meant that the attribute >> will not change during optimization and, similarly, marking it as optimized >> has never meant that it will necessarily be optimized*. For example the >> global coordinates of all members of rigid bodies are set as non-optimized, >> but change. And, marking the z coordinate of something as non-optimized is >> unlikely to ever make it not change (it may trigger an exception though). >> >> Going the a three state `constant` (changes are dropped on the floor), >> `computed` (value is the result of a score state, so changes outside of >> that trigger an error), `variable` (the optimizer can change it if it >> wants) might make the most sense. I'm not sure how expensive adding a check >> if things are constant before setting would be in practice. >> >> >> On Tue, Sep 24, 2013 at 9:43 AM, Barak.raveh barak.raveh@gmail.comwrote: >> >>> I read the issue thread again - so, how does it work right now? >>> >>> On Sep 24, 2013, at 9:37 AM, Daniel Russel drussel@gmail.com wrote: >>> >>> See issue https://github.com/salilab/imp/issues/255. There was (and to >>> some extent is) a lot of ambiguity about how setting individual coordinates >>> to be optimized interactions with telling MC to move them. >>> >>> >>> On Tue, Sep 24, 2013 at 7:24 AM, Davide Baù davide.bau@gmail.comwrote: >>> >>>> Hi all, >>>> >>>> I have a question about the "set_coordinates_are_optimized" function in >>>> IMP 2.0.1. >>>> >>>> In the IMP versions < 2.0, to set the coordinates of a given particle, >>>> e.g., P1 to (0,0,0), I would use the following code: >>>> >>>> > fixedP = "1" >>>> > p = ps.get_particle(index) >>>> > p.set_name(pname) >>>> > if pname == fixedP: >>>> > d = IMP.core.XYZ(p) >>>> > d.set_coordinates(IMP.algebra.Vector3D(0,0,0)) >>>> > d.set_coordinates_are_optimized(False) >>>> >>>> In IMP 2.0.1, even though, at this point, the coordinates of the >>>> particle "fixedP" are set to (0,0,0), the "set_coordinates_are_optimized" >>>> does not seem to work anymore (the coordinates of "fixedP" change during >>>> the optimization). Has this function beed replaced with a new one in the >>>> latest IMP version? >>>> >>>> Thanks, >>>> Davide >>>> _______________________________________________ >>>> IMP-dev mailing list >>>> IMP-dev@salilab.org >>>> https://salilab.org/mailman/listinfo/imp-dev >>>> >>> >>> _______________________________________________ >>> IMP-dev mailing list >>> IMP-dev@salilab.org >>> https://salilab.org/mailman/listinfo/imp-dev >>> >>> >>> _______________________________________________ >>> IMP-dev mailing list >>> IMP-dev@salilab.org >>> https://salilab.org/mailman/listinfo/imp-dev >>> >>> >> _______________________________________________ >> IMP-dev mailing list >> IMP-dev@salilab.org >> https://salilab.org/mailman/listinfo/imp-dev >> >> _______________________________________________ >> IMP-dev mailing list >> IMP-dev@salilab.org >> https://salilab.org/mailman/listinfo/imp-dev >> >> >> >> _______________________________________________ >> IMP-dev mailing list >> IMP-dev@salilab.org >> https://salilab.org/mailman/listinfo/imp-dev >> >> > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev > >